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1.0 GENERAL 


GENERAL 


PREEACE TO.CURRENT_ EDITION SEE COVER SHEET FOR DATED 


hardcopy of the SIS» do {SN452/125 in SVL» SN302 in ARH)2 
acquires$2196/un=dces 

seseprint s2196 

copy on 8.5" x 11" inch paper (in SVL)» add print parameter fc=sp. 


(You may have to wait until evening for copy.) 


For 


current status of pending SIS daps»s see file SISDAPS/pwo0336 on 3N452. 


ADECZBCCB epproved SIS daps Incorporated in this revision are: 


$5036 Change the Key parameter (Wilson) 

$5048 Kevpolnt Ranges (Mages) 

$5059 Statistics (Neuhaus) . 

§5060 Product identifiers for COCNETs DC & NP (Rundaquist) 
$5062 Product identifier fer Distributed Files: DF (Sprandei) 
$5067 Passing BIT data type paremeters (Barney) 


In additions the following pending SIS daPs sre conditionaliy included: 


$5102 Product Identifier for Concurrent Maintenance Utliltiles: CU {Redig) 
$5103 Product identifier for CYBIL Formatter: CF {(Wachutka) 


The 


Following notes wili enable you tc look at updated sections of the SIS 


without printing the entire document: 


For 
For 
For 
For 
For 
1.2 
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The purpose of this standerd is to ensure a uniformity across the operating 
system and product set thet will make the total 


$5036» see section 2626423» change in KEY prameter, 
$5059»9 see section 3.524 Statistics. 
Product identifierss see section 41.1.1. 


550485 see section 4072221 Operating System Keypoint ranges. 


$5067s5 see sections 5e2e1e1 and 5222522 (inciuding its subsections). 
CHABIER 


1 PURPOSE 


human engineered. 


1.2. 


2 SCOPE 


This standard covers the software system which includes both the operating 
system and the product set. The standard covers product-to-product», 
product-to-user,s, operating system—-to-users and product-to-operating system 
Interfaces. These inter feces may be documented in the NOS/VE and product 


system more easiiy Usable and 


OF G6 26 Ge 6 OH BH Oe Ba 4H 4G OH 
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ERSs. This System Interface Standard is the controlling document for all such 
interfaces. 


Any external intefface which is not defined by an industry standard may be 
defined In this System Interface Standard. In order to achieve a uniformity 
across the product set» certain internal interfaces shali be included In this 
standard» e.g. calling sequences. 


With respect to command-level calling sequences» parameterss end optionss this 
standard inctudes (see section 2.2.4) ail options for ali parameters of all 
~—6~calling sequences except those of NOS/VE which are documented in the NOS/VE ERS. 
(Among options of parameters, there may be Inconsistencies from product. to 
product. Such inconsistencies will be removed In the future by daps egainst 
the SIS and code changes» or noted as exceptions - see item 5 of section 1.424 
below. At this times it Is more important to document existing usages in 
order to.sake the SIS compiete than it is to remove inconsistencies and 
conflicting usages.) 
Interfaces in code that do not conform to the SIS» either by commission or 
omissions shouJd be PSRed. The project-defined priority of such PSRs may not 
be tess than serlouss and the such PSRs will not be rejected by projects. 
12223 GOALS 
The specific goals of the System Interface Stendard ere: 

ae Consistency within and across the system. 

be. Human engineered for user. 

c» Achievable within CYBER 180 timeframe. 

de Good performance. 


ee External Interfaces ftike CY170 where this dees not 
conflict with a» by» c and d above. 


There must be more than trivial gein in aspects of human 
engineering to cause deviation from CY170 externa! 
interfaces. 
1.2064 REVIEWING AND UPDATING THIS DOCUMENT 
The C180 SIS has been tarcugh a number of review cycles and has been 
formaliy approved by the C180 Baseline Change Controi Board (BCCB). 
It ts thus considered fairly solid. 


However, it is recognized that the SIS is a living document with a 
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continual need for updating. Please foliow the following guidelines 
in reviewing and updating this document:. 


As 


Qe 
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4. 


Limltt comments or updates to question of inaccuracys lack of 
completeness» or necessary technical changee Avold questisons 
of personal preference. 


For reiatively minor problems or auestions resulting from a 
normal reviews», a normal DCS comment Is apprepriate. it Is the 
responsibliity of the appropriate authoris) to resolve the comment. 


For more major updates that may be Somewhat controversials a 
stand-alone DAP Is eppropriate. This allows a thorough revienr 
of the Issues invoived. When approveds the DAP will be 
included in the next SIS update. The 315 referee or editor 
should be Informed of any plans to submit such a DAP and the 
DAP should be in the form of a proposed SIS update. 


There will be occassional “minor review cycles“ of the SIS to. 
Incorporate minor chenges and previously approved DAPs. 
Authors may make minor changes to their sections at this time 
For review and approval. 


If conflicts exist between two products that cannot be resolved or 
change is impractical, the exception wili be documented In the SIS- 
The nunber of exceptions Is expected tc be very smail. 
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260 INPUT 


This section describes the standard and conventions for 
Input to products. Input standard is defined for System 
Command Languages» Control Statement, source fiie 

or ganization and contents. 


261 SYSTEM_COMMAND LANGUASE 


The System Command Language is the set of fanguage rules 
and conventions to be followed by any software product 
that presents e user Interface (which Is not defined by an 
industry standard). It is documented in the NOS/VE ERS 
(DCS documents ARH3609»s ARH3610). For examples, commands 
to call products» and operator cOmmands wiil conform to 
this language cefinition. It is a requirement that all 
products use the standard command taenguage routines to 
process system command Janguage statements (such as 
product call commends or product cirectives). The intent 
here is that preducts do not dupiicate code or functions 
already provided by standard command language routines.. 
See NOS/VE ERS {(ARH3610) for a description of these 
routines. 


202 PRODUCT CALL _COMMANDS 


This standard specifles the parameters which can be used 
in commands thet call CYBER 180 products. The syntax of 
the command is cocumeanted in tne NOS/VE ERS. 


2e2e0e1 APPLICABILITY 


This section specifies ali parameter names» descriptions 
and defaults of perameters on a command that calis a 
product. Requirements for use of the parameters are: 


‘ If a product offers a capabiiity which Is the same as 
one defined in this standards, then the specification 
in this standard must be used. 

° A product is not permitted to use a parameter defined 
by the standard for a purpose other than that . 
specified by the standards 


e A product need not implement ali the parameters or all 
the parts of 9s parameter In this standard. 


3 New perameter names or options must first be approved. 
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as acditions to this standard. 


If a product provides a function described by a perameter 
in this standards the described parameter name and its 
standard aliases must be supported by the product as a 
minimum. 


ALIASES 


Ae Standard aliases are made up of the first letters of the 
parameter name. Ali products which use the parameter 
must support the standard aliases. 


B. Aliases which do not conform to the first letter rules 
but which have widespead usages can be standerd aliases 
oniy if explicitiy documented as such In section 2224.3 
(Parameter Names and Descriptions) of the SIS. 


C. Non-standard aileses are those ailases which do not 
conform to the first-letter rules but which ere used for 
compatibility with older versions of a NOS/VE product. 
New products should not support non-standard aifases. 
Cicer products mey aant to phase cut their non-standard 
aliases. 


D. 170 compatibie aliases are those eliases which do not 
conform to the first-letter rule» but which sre used for 
compatibility with a 170 product. Products which are 
not required to be compatible with a 170 product should 
not use these eliases. 


Some guidelines for proposing new parameter names and/or 
options are: 


1. 


Ze 


Use anew option of an existing parameter rather than 
anew parameter name if the capability is an extension 
of an alreacy defined parameter (example: use B=DS 
instead of inventing a new perameter DS for debuy 
statements. 


For reiated parameterss use allases thet emphasize the 
relationship (exemple: LO to relate listing options to 
the list files L). 
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20262 TERMINOLOGY 


Default? The value usec for a parameter when the parameter 
does not appear in a command. Section 4.3 on installation 
parameters indicates which parameter defaults are 
Installetion chenseabile. The defaults specified in 
section 2204.2 are those expected to be most often used. 


(20203 SYNTAX 
The syntax of the command is defined in the NCS/VE ERS. 


If a parameter Is omitted, defauit values are used. Use 
of <parameter neme = OFF> results in turning off a single 
option perameter or boolean single specified value 
parameter. Use of <parameter name> = NONE Indicates that 
a specified vatue is not supplied for a muitipie2 value or 
multiple option parameter (for examMpies, LD = NONE céeuses 
none of the list options to be selected). 


When the parameter vaiue is a file name» the file neme 
$NULL shovid be used to negate thet flie ifor examples. 
B=$NULL causes the product not to produce eae binary object 
code file). NULL is a reserved flie name. A read will 
respond with an end-of-information. $NULL Is an infinite 
sink for writes. 


The following aigorithm is applied to parameters: 

1» Initially» eli value options for this paraMeter sre 
considered deselected (j.e. there are no initia! 
values). 


2e Oniy the option(s) specified In the value list sere 
then selected. 


The <name> used on the command to call a product can be 
eltner an allas or a tong form as follows: 


Alias Long Form DeScription 
APL a programming language 
BASIC beginner's all-purpose sy@bolic 


instruction code 
cc The language C 


COBOL cOmmon buUSiness oriented language 
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CYBIL Cyber implementation languase 

EDIF EDITLFILE Edit Screen (for raw text) 

EDIL EDIT_LIBRARY Edit Screen (for Source Code 
Utility libraries) 

FMU file management utility 

FTN FORTRAN formula transiation 

LISP list processor 

MAP Matrix Algorithm Processor 

MERGE merge 

PASCAL Pascal 

PROLOG Programming in Logic 

PLI programming ianguage i 

QU query update 

scyu source code utility 

SORT sort 

VX UNIX system emulator 


2e2e% PARAMETER 


Oscurrence of eny parameter more than once in a control 
statement is an errore 


202041 Positional Orderiong_of Product Set Parameters 


Product set members providing the Is Bs and L parameters 
must support the following positional ordering on a 
Nnon-keyword cali. There is no guarenteed common ordering 
of other parameters to a product set member except what 
might be documented in the reference manual for that 
product. 


1.) INPUT 


20 BINARY (normaliy the main desired output of a compiler) 
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3e LIST 
2020402 Lypas.of Parameters 


See the Command Interface (Part I) of the NOS/VE ERS for a 
description of the file references which Is the syntax to 
be used for specifying a file name es a parameter value. 
If no position is specifieds the product will reposition 
the file before use as fodlows: 


a) for a file nemed SINPUT»s no repoSitioning will 
take place if the file is at beginning of 
Informetions at end of informations or at a 
partition boundary. Otherwises it will be 
repositioned to end of partition tefore use. 


b) for a file naméd SOUTPUT»s the product will do no 
repositioning before use. 


ec) for afl other files» the products will reposition 
to beginnings of information before uses 


Example: If a cali to SCU has been made to write three 
source decks to COMPILE (the first FIN»s the second CYBIL>. 
the third FIN) end they are te be compiled with the object 
code pisced on file LGC» the SASIS positioning must be 
specified on the second and third compilations since 
dafault positioning is rewind. 

FIN I=COMPILE 

CYBiL [{=CCMPILE.S$ASIS, B=LGO.~SASTIS»L=SOUTPUT 

FIN I=COMPILE e$ASISs BE LGO.SASISsL=$0UTPUT 
There are four kinds of parameters: 
{1) Single Specified Value 
This is a parameter for ahich the user must specify a 
values such as a file reference or a boolean as in the 
form: 


Keyword = <boolean> 


where: 

<booleen> 32:3 = <true> ! <faised 
<true>d 2:3 = TRUE ! YES ! ON 
<false> 3: = FALSE ! NO ! OFF 
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For the sake of consistency the velues ON and OFF will be 
used in this document. Products may choose any of the 
values for <true> and <faise> desired and describe the 
choices as such in the product documentation. The 
operating system will accept the values for <true> and for 
<faise> aquivalentiy when the standard command ianguaege 
routines for the control statement processing are used. 

As a resuits users wiil be able to enter any of the values 
for <true> or for <false> without regard for what velues a 
product has chosen to document. 


{2) Multipie Specified Value 


This is a parameter for which more than one value (such as 
filie references) may be specified. The form 
<parameter-name = NONE>D will be used to indicate that none 
of the avallable options for a parameter are desired. 


{3) Single Option 

This is a parameter for which the user specifies 
<option> = ON 

(4) Multiple Option 


This ls a pareweter for which the user may specify the 
names of more than one option. 


For muiltipie specified value parameters the value list 
syntax Is as described in the NOS 180 ERS» Part I section 
"Parameter Lists and Types". <A value list consists of a 
series of value sets separated by one or more spaces or by 
a singie comma. When more than one value set is 
specifjleds, the tist must be enclosed In parentheses. A 
vaiue set consists of a series of values Separated by one 
or more sPaces cr by a singie commae When more than one 
value Is specifled the set must be enclosed in 
parentheses-e- The rule is that an outermost pair of 
parentheses belong to a vaiue iist and inner pairs of 
parentheses belong to value set. 


The form <parameter naMe = NONED will be used to indicate 
that none of avsilable options for a parameter are cesired. 
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2eole%e 3 Parameter Nemes and _desertptions 
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2e20%-3 Parametec_Namsa_sod Descriptions 


The paremeters ere described in aiphabetical order. 


Par ameter Standara 

Name Alias 
AUDIT | A 
BINARY B 


COLLATING_SE QUENCE_X CSA 
CSN 
CSR 
css 


Parameter Description 


AUD Is a non-Standerd alias for AUDIT. 
This perameter is used to indicate that 
the product is being run for audit 
testing. The parameter causes the 
selection of any other parameters. which 
may be needed for audit testing as weil. 
as selecting the method of processing» 
which may differ from normal processing. 
For examples in COBOL the Jist of items 
might include the mode where displays of 
numeric items would not be edited. 


Singie option parameter. DOefauit: the 
option Is not selected, 


AUDIT = ON selects this option. 


BINARY _OBJECT ano BO are non-standard aliases 
for BINARY. 


Binary Ooject code output file. 


This perameteér specifies the file to 
contain the object code or text produced 
by a compiler or assembler. 


B = <file> 


Be$NULL Indicates that no such binary 
object code output file is to be written. 


Singie specified value parameter, 

defauit = $LOCAL.LGO 

If a jist of files ts specified for INPUT», 
then ali the binary outputs accumulate on the 
specified BINARY file. 


SEQY fa a 170 compatibliity alias. 
Coltating sequence (X = Names Steps 
Remainders or Aiter; and Y=N» 3S» Re or Ade 
The parameters SEQN, SEQS» SEQR and SEQA 
control dafinitions of collating 

sequences for an applicable product. 
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CSN. The CSN parameter signals the 
start of a collating sequence 
definitione The definition of one 
collating sequence continues with CSS» 
CSR» CSA parameters; it is terminated 
by any parameter not one CSS» CSR» 
CSA. The form is: 


CSN = <name>» where name is the name of 
the collating secuence- 


CSS. Each CSS perameter specifies 
either a single Step or a range of 
steps. The form is: 


CSS = <value-list>, where the 
expressions In the value fist are 
character expressions. 


CSR. This parameter specifies alii 
charecters In the chafecter set not 
specified in a CSR parameter, expiicitiy 
or impiicitiy. The form is: 


CSR = ON 


CSA+ This parameter may be specified to 
aiter aii equated characters in output 
records so they become the first 
character in the appropriate CSn 
parameter. The form is; 


CSA = ONe 
COMPILE c Complte file. 


This parameter Specifies the output file 
on which complier source statements are 
written. Examples are: the output 
produced by a conversion aid utility; the 
updated source output by the source 
maintenance utility for Input to an 
assembier or compiler. 


Single specified value parameters 
default = COMPILE. 


COMPILATION, Cc) If selected» compilation directives (see 
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DIRECTIVES SIS section 2.4) will be recognized. 
Otherwise compilation directives wlii not 
be recognized--l]f directives are expressed 
as a special form of comment they will be 
treated as are ali other comments. 


Single option p8@rameter. Default = ON» 
directives are recognized. 


CL7O0_ COMPATIBLE cc If selecteds al! possibile CYBER 17C to 
CYBER 180 product differences wiil be 
converted to the CY180 version or 
diagnosed with messages. For examples in 
COBGL items specified as COMP-4 will be 
assumed to be COMP. Aili products which 
support this paremeter must provide a jist 
of such convefsions or assumptions In their 
manuals. 


Single option parameter. Default: the 
eption is not selected. 


C17C_COMPATIBLE = ON seiects the option. 


DEBUG_ATDS DA Debugging aids. 
This parameter specifies the debug options 
to be selected. Ail products need not 
support all options. Muitipie options may 
be specifled. The defined options are: 


ALL All of the available options ere selected 
for the DEBUG_ AIDS parameter. 


DS Debugging statements. Ali. debugging 
statements wil! be compiled. A 
debugging stetement Is a stateszent in 
the source which Is ignored by the 
product unless this option is 
specified. Debugging statemants 
usually specify debug actions for the 
modul2 containing them. See aise 
section 224.7 of this standard. 


OT DEBUG TABLES. Generate iine number 
end symbol tables as part of the 
object code. 


oC Gbject code regardiess. Produce 
object codes, regardiess of errors in 
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the source and severity of such 

errors. For compilers» execution of a 
fine containing a fatal error shouid 
result In a cail to an object time 
routine which will terminate the 
execution with a message. {See 

section 3.4 for error status returned.) 
Products with no object time tibrary 
may generate @ zero (program error) 
instructon for lines in errore 


PC Paraneter checking. Generate peraemeter 
checking information as part of the 
object code. If PC is specifieds 
any complier which supports parameter 
checking willl generete actual and 
formal parameter dscription 
information In the object code to 
enable jload-time detection of 
parameter mismatches. 


TR Fiow tracing. activate trall pragmats 
in the source program. Uniess TR Is 
specifieds trsece pragmats have no 
effect. 


Multiple option parameter. The default is 
DA=NONE 


DEFAULT_COLLATION DC This parameter specifies the weight table 
to be used for the evaluation of character 
(string) relational expressions and to be 
used by intrinsic functions which ere 
collated sequence dependent (for example 
CHAR and ICHAR tin FORTRAN). The defined 
options are: 


U or USER 
A user specified weight table is 
used. In FORTRAN a@ collection of user 
callaole procedures Is provided for 
manipulating the user weight teble. 


Fo or FIXED 
A fixed ({unmodifliable) processor 
specified welght table is usede 


Single specified value parameter, 
défauit = FIXED. 
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DIRECTIVES_FILE DF DIRECTIVES Is a non-standard allas. 
DIR is a non-standerd and a 170 compatibie allies. 


Additional parameters will be read from 
this file after eil of the control 
statement parameters have been reads 


DF=file-name 
Parameters will be read from filles. 
flile-name. 


DF=(file-namellsfile-nameZ] . » «) 
Parameters will be read from the 
files in the order that they are 
named, 


Multiple specified value parameter » 
default = NO ADDITIONAL PARAMETERS ARE 
READ. 


ERROR E Error file. 


This psrameter sp@cifies the name of the 
file t© reacelve efror tlisting 
information. In the event of an error 
fof EL specified severity or higher) the 
diagnostic is written to the E file. It 
is highly recommended (though not 
required) that a product also output the 
offending source iine or lines to the E 
file in conjunction with the diagnostic. 
If there Is a listing file (see L 
parameter) the error fine and diagnostic 
are also written to the L file. If the 
file name of the E File is the same as 
the file name of the L files then the 
error line and diagnostic are not written 
twice. 


Single specified vaiue parameters 
default = SERRORS 
ERROR_LEVEL EL Error Level. 


This option Indicates the severity level 
cf diagnostics to be printed on the 
user's listings The levels are ordered 
by increasing severity. Specification of 
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a particular tevel selects that ievel and 

ail more Severe levels. Products will be 
allowed some flexIlbility in specifying 

the kinds of diagnostics that fail In 

each of the four categories: iInformationals 
warnings fatals end catastrophic. The 
following descriptions are provided es a guide. 
The leveis in increasing order of severity are: 


I Informational. This is an infor®ational 
message used to fiag a suspicltlous usage. 
The syntax is correct but the useage is 
questionable. For 170 compatibility oniys 
products are free to use 4T* in addition to 
"I". (However, if only one is useds it must 
be I.) OGutput must elways be *I*» never *T*. 


W Warning. This Is a@ dlagnostic where 
the syntax is incorrect but the 
product has made an essumption (such 
as adding a comma) and continued. 
Messages indicating attempts at error 
recovery are at this level. 
Diagnostics of W teve!l should be 
errors that the user can aycid by 
program modification. 


F Fatal. This is a diagnostic which 
prevents the product from processing 
the statement in which it occurs. 
Unresolvable semantic errors aise 
fall into this class. Such errors 
may not relete to a specific 
statement in the program unit. 
Errors of type "ERROR! will be 
treated as equivalent to *FATAL*. 


Cc Catastrophic. This class of error is 
fatai to continued processing. The 
product is unable to continue work on 
the currant program unit. However, 
it should stitl advance to the end of 
the current program unit and attempt 
to process a subsequent unit (if the 
product specificaton aliows muitipie 
program units in a compilation). 


Single speciflea value parameters 
default = We 
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EL=NONE causes no errors to be listed. 


ESTIMATED NUM BER_ ENR Estimated Number of Records. 

RECORDS This parameter specifles the estimated 
number of records to be processed by a 
producte For examples SORT can use it to 
cause selection of efficient modes of 
processing» 


Singie spacified value parameters 
default = 80000/MRL. 


EXCEPTION, ERF This is a file containing exception 
RECORDS_ information. Products will be ailowed 
FILE flexibliity in defining Its contents. 


For exampies SORT MERGE will use it for 
out-of-order merge input records, 


Single specified value parameter, default 
is product dependent. 


EXPRESSTON_ EE The options of this parameter control the 

EVALUATION styie of code generated for the 
evaluation of source expressions. Note 
thet the processing controlied by this 
parameter Is separate from that 
controlled by the optimization tevei 
parameters» but may affect the extent to 
which optimization is possibie. The 
defined options ares 


C or canonical 
The code generated to evaluate an 
expression will mirror the expression 
interpretation rules as defined in 
the product specification. For 
FORTRAN this would be section 6 of 
the ANSI standard. This option also 
serves to Inhibit the CCG “regroup” 
option. 


ME or maintain exceptions 
Inhibit code optimizations which 
eliminate instructions that might 
cause hardware exceptions at 
execution time. This option also 
serves to inhibit the CCG 
“unsafe to _safe™ option. 
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MP or maintalnuiprecision 
Inhibit code optimizations which 
change a flosting point operation to 
anew form that is mathematicaily 
equivalent but not computationelly 
equivalent. This option also serves 
te select the CCG “maintain. 
precision” option. 


R or reference 
Intrinsic functions (€e9- those 
defined in CMML) for which a 
procedure call is generated will be 
calied by reference rather than by 
values 


Multipie option perameter. 
Defauit = NONE» rone of the options Is 
selected, 


EXTERNAL_INPUT EI EX_- INPUT is a non-standard alias. 


This file is for use by products which 
provide the capability of temporarliiy or 
aiternstely obtaining source statenrents 
from a file external to the input file. 
For examples the COBOL COPY statement. 


Single specified waiue parameter; 
defauit = $NULL. 


FASTIO This perameter can be used only by SORT/MERGE. 
This parameter is on the predecessor product». 
SORT 5 on the CYBER 170, and is for compatibility 
oniy. This perameter has no effects will go away 
at a jater releases anc will not be dcescribed 
in the reference manual. 


FORCED_USAVE FS If selectad, the definition status, of 
ali entities within a subprocedure of a 
program wili be retained upon exit from 
that subprocedure. Effectively this 
disailows placing any variables on the stack, 


Single option perameter. Default = OFF, 
definition status need not be retained 

except where so required by the product 
specification. ; 
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FROM F Cid file. 


This perameter specifies the data input 
file for the procuct. For example: the 
file ffom which e copy utility reads. 


Multipte specified value parameter ; 
default = OLD. 


INPUT I Input file. 


This parameter specifies the source input > 
file name to the product. Where reasonable, 
alist of File nemes is aliowed. 


Muitiple specified value parameter; 
default = SINPUT. 


INSTRUCTION, Is This parameter specifies whether or not 
SCHEDULING instruction scheculing will be. performed. 


Single option boolean parameter ; 


YES This option selects the parameter. 
default = NO 
omitted is same as NO 


INTERACTIVE, II This parameter determines whether the product 

INTERFACE will initiate Interactive processing with the 
user» instead of operating in Its usual batch- 
oriented fashion. This consists of displays 
written by the product to file SOUTPUTs and 
user-supplied answers from the flie SINPUT. 
The Interactive Interface can be Invoked 
either from an Interactive terminals 
or a batch jobe 


Single option boolean parameter: 


YES This cholce tnitiates the Interactive Interface. 
The processing of aii other parameters on the 
command line is Product dependent isee the 
appropriate product manual)» except that the 
STATUS parameter is never Ignored. The product 
mays but is not required to» allow the user 
to decide Interactively whether cr not the 
other parameters on the command iine are to be 
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ignored. 
NG Do not invoke the interactive Interface.» 
omitted Same as NQ. 
KEY K Key Fietd(s). 


This parameter specifies the key fields 
thet cetermine the manner in which Input 
data might be processed by a product. 
For exampies SORT will use the parameter 
to determine the order records will be 
sorted. 


KEY=<value-list> 


The format of the KEY parameter is 
product dependent. 


LEADING  BLANK_ZERG LBZ If selecteds leacing blanks in Numeric 
fields are treated as zeros in arithmetic 
statements and comparisons. If not . 
selecteds numeric fleids that contein 
blanks are in error. 


Single option parameter. Default: the 
option is not selected. 


LBZ = GN selects the option. 
LIST L . Listing file. 


This parameter specifies the filie xhere 
the product writeS the source listings 
Glagnostics,s, statistics,» and any 
additional list information (see LO 
parameter). 


Singie specifled value parameter, 

cefesult =$LIST. 

If a tist of files is specified for input» 
then ali of the List outputs accumulate on 
the specifiecg LIST file. 


LIST LOPTIONS Lo Listing options. 


The options of this parameter specify 
what extra Information will appear on the 


ee ee on we 
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listing flie (LIST parameter). Multiple 
oPtions may be specified. The defined 
options ares 


A Attributes. <A listing of the 
attributes of each entity defined 
within the program is produced. If 
R was selected, the references area 
shown on the same listing. See 
section 3.3.5 for more informetion 
on attributes. 


8 Prohibit Banner. The banner Js not 
sent to the Listing file. 


BO Byte Offset, (Release 2 festure). 
If source statements are listed» an 
offset fiela is included (see 
section 3.323+3). This option is 
meaningful oniy for wide format 
listings. 


DE DETAILED EXCEPTIONS. Print out 
exception flie messages aS often as 
a record Is sent to the excepticn 


M Map. <A storage iayout map for 
comuon biocks and equivalence groups. 


MS Merge Statistics. Turn on tisting 
of merge stetistics. 


C Object code fisting. A isting of 
the generated object code with 
instruction mnemonics. 


P Prohibit preempt. The normal input 
prompts afe not sent to the Listing 
fiie. 

R Cross reference listing. A cross 


reference of program entities 
showing tocetions of definition and 
use within the program. 


RA Cross reference tisting of ail 
progfam entities whether referenced 
or note 
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LITERAL CHARACTER 


LOADLCOLLATING TABLE iCT 


MACHINE DEPENDENT 


LC 


MO 


RS Record Statistics. List the 
statistics for the records 
sorted/merged. 


S Source. Source listing of the 
program. 


SA Source listing of all source 
statements including lines turned 
off by a source embedded NOLIST 
directive. (See section 2.4.2) 


Muitipie option parameter, default = 5. 


LO = NONE causes none of the fist options 
to be selected. 


This parameter can be used to change the 
character that delimIits non-numeric 
literaise Default iiterali character Is 
quotation mark. 


ic=OFF is an error. 


This parameter icads an external weight table 
and associates it with a collating sequence name. 
The format of the table is AMTSCOLLATE_TABLE.. 


LCT=(COLLATING SEQUENCE NAME», WEIGHT TABLE NAME) 
DEFAULT=n90 weight table is loaded. 


This parameter specifies whether use of 
machine dependent source features is to 
be diagnosed and If so» how severely. The 
severity level Is one of the folloning: 


I or informational! 
W or warning 
F or fatal 


Errors of type "ERROR® will be treated as 
equivalent to FATAL’. 


Singie specified walue parameter. 
Defauit = NONE» machine dependencies are 
not to be diagnosed. 
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MASS USTORAGE_ LIMIT MSL Mass Storage Limit. This parameter 
sPecifies the maximum number of 
characters that may reside on mass 
storage during execution of the product 
ifor examples SORT). 


MSL=expr. The number of characters 
indicated by expr Is the mass storage 
limit. Exer must be an Integer. 


OMIT DUPLICATES OD This perameter controis omitting ai but one of 
the records which have equal key values. 


OD=ON Omit all but one of the records with 
equal velves. 


CO=OFF Do not omit duplicate recorcs. 
DEFAULT = OFF 


ONE_TRIP_DO OTD This parameter selects the minimum trip 
count for FORTRAN DO-loops to be one 
rather than zero. 


DPTIMIZATION OL GPTIMIZATION and OPT are non-standard siiases.. 

LEVEL 
This parameter specifies the levei of 
ebject code optimization. Ail products 
need not support aii defined levels. 
However if preduct supports a defined 
fevel, it must be seiected by the 
specified option name» Ideally ali 
products which support this parameter 
should recognize ail defined 
options and issue informative diagnostics 
for unsupported options that the user 
selects. Alfiowable options are: 


DEBUG Object code is stylized to 
Facilitate debugginge Stylized 
code contains a separate packet 
of instructions for each 
executable source statements. 
carries no variable values 
across statement boundaries In 
registers, notifies DEBUG each 
time a beginning of statement or 
procedure is reacheds etc. 
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LOW Lowest !@veil of production 
quality code. Code Is not 
completely stylized. 


HIGH High level of production Guality 
code. 


Singie spacified value parameter ; 
defauit = LOW 


OUTPUT o This parameter specifies the file where an 
interactive product wfites its output. 


Singie specified value parameters, 
default = sOUTPUT. 


QWNCODE_ FIXED. OFL OWNFL is a 170 compatible alias. 

LENGTH This parameter specifies the record iength 
in characters of all records that will be 
input to a product from any owncode 
procedure. See elso OMRL and OPn parameters. 


OFL = <Integer>.» Every record supplied 
by an owncode procedure wili contain 
exactiy <Integer> characters. Default: 
(See OMRL). 


OWNCODE, MAXIMUM_ OMRL OWNMRL is a 170 compatibility allas. 

RECORD LENGTH The maximum tength in cheracters of any 
record supplied by any owncode procecure 
is specified by this parameter. This 
parameter may not be specified if the 
product has input or output files and if 
eny of their associated MRL*s are st 
least as large as this MRL. See aiso OPn. 


CMRL = <jnteger>. There witli be at 
most <integer> characters In any records 
supplied by an owncode procedure. 


Defauit: If OFL and OMRL are both 
omitted, the record langth specification 
will depend on the length specifications 
of the input and output files. If all. 
Input and output files have fixed-length 
records of the same length that length 
will serve as the default for OFL. 
Otherwise the largest MRL or FL from any 
input or output file will serve as the 
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OWNCODE_ PROCEDURE LN 


RE SULT_ARRAY 


RETAINL-ORGINALL 
ORDER 


CPa 


RA 


RCO 


defauit for OMRL. 


OWNn is a 170 compatibility alias. 
Bwncode procedure nin = ly 2s 39 4s 5s 
eeeoe)s The maximum of n is jeft te the 
individual product. Owneode procedures 
sre user written routines that may be 
loaded with the product and executed at 
specified points during product 
execution. See other OWNCODE 
parameters for more Information on this 
capability. 


The Procedure specified by this 
parameter will be executed at a 
specified point n during product 
execution. 


OPn = proc name. The procedure 
proc name will be executed at a 
specified point ne 


Default: No procedure will be executed. 


RESA is a non-standard alias. This perameter is 
used to return all or part of the result array. 


RA=array name, an SCl array 


Defauit: Do not return afy information from the 
result erray. 


RETAIN and RET are non-standard and 170 
compatibility aliases. 


Equivalent records or records with 
equivalent identifying characteristics 
will be cutput In the same order as 
input by a product. For examples with 
SORT» the equivalent identifying 
characteristics nould be equal keys. 
The order in which multipte input files 
are specified is the order In which 
records with equivalent characteristics 
are retained with this parameter. 


RGO=GN. Records with equivalent 
cheracteristics wili retain their 
original order. 
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ROC=GFF. Records with equivalent 
characteristics will not necessarily 
retein their original order. 
Default: Same as ROOG=OFF. 


RUNTIME CHECKS RC This pafameter controis which runtime 

| checks are compiled into the object 
code and/or selected for runtine 
Yibrary routines» Runtime checks are 
product dependent but If a product 
supports one of the ones described 
heres Jt must be selected by the value 
specified. Defined values are: 


ALL All supported vaiues are selected. 


F Files checking. Selects checking of 
errors invoiving file variabies and 
buffer varilebjies. 


N Pointer checking. Selects checking of 
misuse of pointer variables. 


R Range checks. This option selects 
range checking for one or more of 
the following 
~ sheracter substring expressions 
- scaiar subrange assignments 
- case varliabies 


S Subscript checks. This option 
causes subscript and index. 
references to be checked to ensure 
that they are within program 
defined limits. 


T Tag fleld checks. Selecting this 
option ensures that accesses to 
variant records are consistant 
with the value of their tag field 
{if one exists). 


This Is a multiple Vaiue pafameter. 
Default Is RC=NONE. 


SCREEN NAME SN The name identifying an object screen 
definition to be retrieved from the 
user*s object ilibrary. 
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Single specified value paramter. 
Optional, no default. 


SEQUENCED_LINES $L This parameter selects FORTRAN 
sequenced mode source tine format as 
described in section 3-2 of the FTN180 
ERS. Note that this format is 
incompatible with the standard $15 
(section 2.3.2) source line format 
which allows the length and location of 
a iine number to be specified in the 
source file attributes. 


Single option perameter. Default = OFF» 
source iines conform to the standard 
SIS format. 


SESSION TYPE $T One of the keywords EDIT» HELP, UTILITY. 
Used to present initial SOF session 
environment. 


Singie specified yvalur parameter. 
Optional, no default. 


SOURCE 5 SCU Input. 


Line images of the generated program 
wiil be written to this files in a 
format acceptable as input to SCU. 

Each program unit on the S file wiil be. 
preceded by an SCU directive which 
indicates the beginning of a new source 
decke 


Singie specified parameter values 
defauit = NULL. 


STANDARDS _DIAGNGSTICS SD Standards diagnostics. (ANSI or other 
applicable standard). 


This parameter specifies whether use of 
non-standard input source statements 
are tc be diagnosed and if so» how 
severely» There are two velues 
defined: severity» and name of 
standard. The severity is one of the 
foliowing: . 


STATUS 
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I Informational error. Standards 
errors are treated as errors with 
this severity. 


W Standards errors result in warning 
messages. 
F Fatal error. Non-standard usages 


result in a Fatad e@rror. 


Errors of type "ERROR*® WIil be 

treated as equivalent to *FATAL*. 
The second values name of standards Is 
to be defined by the products as 
eppropriate. If this parameter is not 
specifieds then non-standard extensions 
to the product are alloweds (not 
diagnosed as errors). 


S$D=NCNE causes standards errors not to 
be diagnosed. 


Multiple specified value parameter» 
default = NONE. 


STATLS Status Variabie. 
No afias is permitted for STATUS. 


All products are required to support 
this parameter. 


This parameter Specifles the name of 
the SCi status veriabie to be set by 
the product to indicate the occurrence 
of error conditions. See sections 3.4 
and 4.4 for an account of the status 
variable, See aiso NOS/VE ERS. 


Single specified value parameter. 


Errors of type "ERROR® wild be treated 
as equivaient to *FATAL'. 


Default: None. 

See Error Processing 

section 3.4 for a description of error 
processing thet resuits from use of the 
default status varlable. 
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SUM $ Sum Field(s). 


This parameter specifies that unIts of 
input data having key fieids equal isee 
KEY parameter) may be combined into 
items or units In a product dependent 
manner... 


(For examples SCRT will use the 
perameter tO combine a1! records» 
having key fleids equal» into a singie 
record. Each sum field in the new 
record is formed by summing the values 
In the corresponding fields of ail 
equal records.) 


SUM=<value~-lTist> 
The Value fist wild contain one or 
more value sets. Units of input 
data with equal key values will be 
combined Into new units or items 
and fields specified by the velue 
sets wll! be summeds according to 
product specifications and needs. 


Multiple specified value parameter >» 
default = NO SUM FIELDS. 


SUBPROGRAM SP is a non-standard alias. 
If this option Is selected» the program 
is compilec aS a subprogram instead of 
as amain program. 


SUBPROGRAM = ON selects the option. 
Default: the option is not selected. 


TAPE_SCRATCH_FILES TSF Tape Scratch Files. 
The tapes with the names specified by 
this parameter wili be used by the 
product to reduce the disk space used. 
The tapes must have already been 
fone prior to execution. The form 
$: 


TSF=(file-name »sfile name .2.) 


Defauit: Tape scratch files wii! not 
be used. 
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TARGETLUMAINFRAME ™ This parameter specifies the machine for which 
code is to be generated. The defaults if no 
option is selected» Is the machine on which 
compilation is performed. 


C1iSOMI or CIS80_MODEL_L INDEPENDENT 
The code generated wii] run on any 
Cyber 180 model. 


Ci80V or C180_ VECTOR 
The code generated will run on any 
Cyber 180 model that has vector 
instructions. 


default = omitted 


TERMINATION_ERROR_ TEL This parameter specifies the minimus 

LEVEL diagnostic severity ftevel which will 
cause a product to return an abdnorszal 
STATUS upon completion of processing. 
A normal status Is returned otherwise. 
The severity level is one of the 
following: 


I or infor@ational 
Wor warning 

F or fatal 

C or catastrophic 


For 170 compatibllity only» products are 
free to use *T* In addition to *I* (howevers 
if only one is useds it must be *I*)- 

Output will always use #I't, 

not 47%... Errors of type "ERRGR*® will 

be treated as equivaient to "FATAL'. 


Singie specified value parameter» 
default = F. 


TEXTLNAME ™N Names of texts to be read from the 
files or libraries Specified by the 
TEXT_RESIOENCE parameter. The totai 
number of values ajlowed is product 
dependent» Products that have a text 
name directive may choose to support 
the TEXT_RESIDENCE but not the 
TEXT.NAME parameter. <A fatal error 
occurs If any of the texts specified is 
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not found. 


Multiple specified value par amater» 
default is no text.. 


TO T New file. 


This parameter specifies the data 
output file for the product. For 
example: file to which a copy utility 
writes. 


Singie specified value parameter ; 
default = NEW. 


TEXTLRESTIDENCE TR Nemes of residences (i.e. files or 
libraries) to be searched to find texts 
specified by the TEXT NAME parameter or 
by product directives. The total 
number of values allowed is product 
dependent. If no text names are 
provided the first text of the first 
TEXTLRESIDENCE name is the only one 
used. If text nemes are provided ana 
TEXT_RESIDENCE Is omitteds the default 
for TEXTLRESIDENCE will be the 
TEXT_NAME parameter list. In case 
texts of duplicate names exist» the 
first one found lin the order in which 
TEXT_LRESIDENCE names are fisted) is 
usec. For seach name In the 
TEXT_RESIDENCE parameter lists the 
product will fiook for a iccal file with 
that name; if not founds the global 
library set will be searched for a 
library with that name. If the name is 
not founds as « fiie or librarys a 
fatal error wlll occur. 


Muitipie specified value parameter. 
Default value list is text name value 
list. 


example 1: if file Fl contains texts A» Cy» and D 
end library 12 contains texts B and C 
anc file F3 conteins texts © and A then 

TN=({AxBaCv00E) and TR=(Flsl2,sF3) 
widl result In selecting texts as 
follows: 
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A» Cy and D from file Fi 
8 from library t2 
E from file F3 


example 2: In the above exampte, if In addition to 
a library L2,s the user has a local file 
named L2 containing texts B and £€» then 
TN={AxBsaCaDsE) and TR=(Fl»sLl2sF3) 

will resuit in selecting texts as 
follows 

A» C» and D from flie Fil 

Band — from file 12 

nothing from illbrary 2 

nothing from file F3 


TERMINAL_ TYPE TT Terminal TyPe,. 


TT=CGR 
Correspondence Selectric APL 
terminal. 


TT=APL 
This type is appropriate when the 
communications system transtiates 
APL terminal codes into a standard 
Intermediste code. 


TT=aASCIil 
For full ASCII terminals not 
eguipped to print the APL 
character set. Also used for 
non—-APL correspondence terminais. 


TT=UCA 
For full ASCII terminals. This 
avoids frequent use of the shift 
key for tetters-. 


TT=BATCH 
For devices that support the ASCII 
64-character set. Usually used 
for batch or remote batch ASCII 
printers. 


Single specified value parameters. 
Defauit is APL for a time-sharing job; 


and BATCH for a batch or remote tatch 
job. 
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VECTORIZATION_ VL VECTORIZATION end VEC are non-standard aliases. 
LEVEL This parameter specifies the vectorization 
jevel. The aliowabie options are: 


HIGH Production—quality code with a high 
jevel of vectorization is genereted. 


IL or INNER LOOPS 
Bniy inner loops are candidates for 
wectorization. 


NONE VEC=NONE causes no vectorization to 
be performed. 


Default = NONE 


VERTFY_MERGE_ VMIC VERIFY and VER are non-standard end 
INPUT_ORDER 170 compatibiiity aliases. 


Verify merge Input order. Selection of 
this option causes verification that 
input records to be merged are in 
correct order. The form Is: 


VMIO=ON. Verify for correct order. 
VMIO=OFF. Do not verlfy for 
correct order. 


Default: VMIO=OFF. 
WORKSPACE WS Initial Workspace specification. 


This parameter specifies the workspace 
to be activated when the product Is 
cailed. The parameter is specified 
with values consisting of the follioning 
parameters defined in the NOS/VE ERS: 


file 
2°3 SOURCE_LINPUI 


This section deais with the standard for the processing of 
source input filles by product set members. In this 
contexts a file can refer to data originating from an 
interactive terminal as well as conventional storage 
cdavicese This standard addresses the ereas of source file 
organizations statement formats piank compressions and 
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response to an empty input file situation. 
2e3e01 SOURCE INPUT FILE ORGANIZATION. 


Source Input to CYBER 180 product set members may be 
dasignated by the I directive on the contro! statement. 
If the I directive is omitted, the source Input defaults 
to the standard input file (batch mode) or terminal 
{interactive mode). The source input has a sequential 
structures and is accessed by means of standard Record 
Manager interfaces. 


Positioning of the source input at open time is 
constrained by the requirement to aljiow different product 
sat members within the same job (e.g. different compilers) 
to access the same file for thelr Input. Therefores the 
source input Is opened with no-rewind uniess the rewind 
parameter Is specified on the control statement (see 
Keywords and Perameter Descriptions In section 22). 


22302 SOURCE STATEMENT FORMAT 


Each record in the source input contains cne to three 
parceis of datas 


7 statement Identifier (optionai); 
. line number (optional); 
* stetement tbody. 


Products should be able to handle the optional statement 
identifier and iine number. 


The source input statement may take the following forms, 
where 


b represents the statement body» 
j represents the line numbers 
s represents the statement identifier, 


and brackets specify the optional portions of the form: 
an ne) 

s 1b 

s bil 

ibs 
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2034201 Statenent._Isentifier 


Input sourc® records may contain optional statement 
identifilefs such es SCU identifiers. If presents they 
occupy either the first or last "n*' charecterss where *n?* 
has a maximum velue of 18. If the statement identifier 
occuples the lest character positions of a records ali 
records must be the seme length. The location and tength 
of the identifier are flie attributes; they are made 
available via en operating system request. 


This festure is to allow files created by SoUfce code 
utilities to be used aS source input. 


2232222 Line Numbers 


Line numbers are numeric entities used by compilers and 
editors. In generals editors will affix iine numbers to 
lines and compilers will use these line numbers for 
diagnostics» cress reference mapss run time error 
messages» etc» Line numbers should not be confused with 
statement identifiers that are produced by SCU and are 
alphanumeric. 


The location of the line number in a text line may te 
immediately to the left or the right of the text of the 
line. The position of the line number field is conveyed 
via the flle ettributes. The fine number fleid may be 

from one to six characters in sizé.s. The only valid 
characters In the field are bianks and the decimal digits 

0 to 9. Leading blanks are Ignored. A line number is 
terminated by end of field or one or more biank characters. 


Additional semantics for the tine number fleid will vary 
from processor to processor. In particulars many 
compllers may not accept more than six digits. Another 
example is the cross reference map produced by CCM which 
only has space for a six digit jine number. Most 
processors wlll aiso insist that the line numbers be 
uniques ascending» and that every fine be numbered. 


2032-3 Statement. Body 


The body cf each source Input record is thet part which 
represents the data to be scanned or processed by a 
product set membere It begins in position 1 If there are 
no statement Identifiers, or if the identiflers appear at 
the end of the record. Otherwises it begins in position 
{(n+1) where ‘n* is the fength of the statement identifier. 
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The maximum size of the statement body is product set 
member dependent and conforms to the size specified for 
the associated language. Source records shorter then the 
maximum are scanned to the end of the record. Records 
exceeding the maximum size are truncated (i.e. data is 
transferred up to the maximum); a diagnostic Is returned 
by the Record Menager. 


2.34264 Blank Comperesslon 


Tne CYBER 180 Record Maneger iS Fresponsibie for 
cOmpression/expansion of blanks. The capebility to read 
the source input in compressed form Is not provided. If 
the requirement for this capabiliity emerges (for 
performence optimization)» it wili be addressed in a 
revision to the standard. 


2.322.5 Empty Ineut_file 


Diagnosis of an empty input file resuits in the issuance 
of a stendard iog message: EMPTY SOURCE INPUT FILE. 
(formatted in accordance with conventions stated in 
section 3-2). If the job Involved is interactive in 
origins the message is also sent to the terminal (see 
sectlon 3.221.222). In additions generation of the primary 
output of the product set member Involwed (e.g. file 
specified by 8 parameter for compilers) is suppressed and 
the SCL STATUS variable irefer to section 22224.2)s Is set 
to reflect the error. 


2232.6 Null Source Line Convention 


The number of records in the source fille should be the 
same as the numter of Soufce tines in the source list. 
Even though a nulf record has no datas the record should 
not be ignorede Sinces In the source lists the absence of 
eli characters in a recerd looks the same as a record 
containing ali tiankss null records should be mappec to 
all blanks. 


22323 DISPOSITION GF INPLT FILE 


The final acticn to be taken with respect to the source 
Input file Is cependent on the manner of termination of 
the product set member. For normal terminetions the Input 
file is closed with the no-rewind option; this Inctudes 
the case where en empty file is detected. For abnormal 
terminations the preduct set member Is responsiblte for 
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positioning the input file as If normal processing had 
occurreds using apprepriate faclilties of the Record 
Manager. 


2.4 COMPILATION DIRECTIVES 


The usér of a Compiler may control various activities of 
the compiler by specifying one or more compile time 
directives. The directives are expressed either In a 
special form of a comment within « particular language 
{e.g. FORTRAN» COBOL) or In specie! source statements If 
the language provides such statements (e.g. CYBIL). 
Compilers that already have special source statements for 
directives do not have to process directives embedded 
inside comments. Compilers which now have compilation 
directives in comments should honor both old and new 
directives. When a compilation directive conflicts with a 
control statement parameter options the compilation 
directive overrides For exampies the options for the 
parameter LO willl be overridden by a conflicting directive 
unless specificeiily stated otherwises such as LO=SA. 
However control statement parameters denoting file status 
or destination would take precendence over directives. 

For example LIST=S$null would take precedence over any 
directives requesting that something be listed. 


Since the major programming langueges are subject to 
standardization by bodies such as ANSI» FIPSs and ISO» 
initial complisence with the form of compiitation directives 
in this section may have to be aitered in the event of 
standards covering this area. Because of the long term 
possibility that the major languages wiil be differents 
fuli uniformity across 180 products is unlikely. 
Therefores products with CYBER 170 directives that do not 
conform to the syntax contained here should retain. 
compatibility with the CYBER 170 form to minimize 
migration problems rather than cause a conversion in going 
to 180 and possibly have to cause a second conversion to 
comply with external standards. New directives in sreas 
which wlil never te subject to standardization should 
follow the form of this section. 


The Compilers support two generai classes of directives: 
* Compiler Cadi directives 
. Source Embeoded directives 


As discussed in section 2.2» the directives specified on 
the command calling the compiler are established for the 
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entire compliiation process. They apply to ali subsequent 
compilation units (program mocules or subroutines) within. 
the compile Precess. 


Source embedded directives are established only for the 
compliation unit in which they appeer. They afe expressed 
either in a special form of a comment within a particular 
language (@eg. FORTRAN, COBOL) or In specie! source 
statements if the language provides such statements (€e9. 
CYBIL). Compilers that already have special source. 
statements for directives do not have to process 
directives embedded inside comments. The syntax of a 
conmplier directive within a comment is as follows:. 


$ directive [( »sdirective ] .«.« » « 


Example - FORTRAN source embedded directives 
Ct directive - C in column 1 


Exampie - CCBCL source embedded directives 
*% directive - * in column 7 


Multiple directives mey be contained on the same input 
statement. 


Where directives have parameters, they follow $CL rules. 


Source embedded directive format errors are clagnosed with 
warning or fatal class error messages» as appropriate. 


The following standard applies to compilers that process 
directives embecded Inside comments. A complier is not 
required to implement all the features iisted belows nor 
is the list restrictive. 


Ze%el PAGE EJECT 
EJECT 


This directive causes the page Jine counter to be reset 

to ie When the line counter Is reset to 1» a standard 
Jisting header will be written on the source listing prior 
to the next source line.» This directive will be listed 
before the page line counter is reset to 1. If the page 
is at top-of-form when this directive Is processedy it Is 
processed as a "nO-op". If a continuous page Is being 
written» this directive will simply result in a triple 
space without e new listing header. 
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2e4e2 SOURCE LISTING 
LIST and NOLIST 


The NOLIST directive causes the listing of the source 
module» Incuding compiler directives» to be suppressed at 
this point. The LIST directive ceuses the listing cf the 
source module tc resume at this point. The directives 
LIST or NOLIST ere tisted at the fsoint they occur. 


2e423 LINE SKIP 
SPACE = number 


This directive causes the specified number of print lines 
to be skipped at the point in the source module listing 
that it Is processed. This directive will be listed 
before the skip action starts. If the page line counter 
is exhausted before the specified number of tines have 
been skipped» the tine counter Is reset to 1 and skipping 
terminates. 


number 2: integer value 1 thru n3; if omitted 
{inciuding the "=")», the default is 1. 


2040301 LINE_SPACING 
SPACING = number 


This directive specifles the number of Lines to be 
advenced before each source fine is listed. The new value 
for spacing will take effect with the next line folloning 
the spacing directive. when listing a source tine If the 
page ilne counter is exhausted before the specified number 
of iines have been skipped» the tine counter is reset to 1 
and skipoing terminates. 


number: Integer value 1 thru 3 indicating singles 
double or triple spacing; if omitted 
{including the "x™)»s the default is "1". 


264%e% TITLE LINES 


TITLE = character string 

SUBTITLE = cheracter string 

These directives define strings of aiphanumeric characters 
In SCL formet which will be printed folionwing the standard 
page headers on the source module listing (see TITLE Lines 
in section 3). TITLE causes a page eject to occurs uniess 
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the page is already at top-of-form. TITLE is listed at 
the top of the new page. 


SUBTITLE also ceuses a page eject to occurs uniess the 
page iS already at top-of-form or TITLE has just been 
processed. SUBTITLE is listed at the at the top of the 
page follcwing TITLE if there Is one. 


Compitation Directives 

20405 RANGE CHECK 
RANGE and NORANGE 
The RANGE directive directs the compiler to generate 
edditional object code which performs range checking for 
subscripts» indexes» scalar assignmentss cese variables,» 
etc. 


The NOCRANGE directive directs the compiler to not generate 
additional range checking object code. 


The default for the compilation unit Is NGRANGE. 
2240265 EXECUTION TRACE 
TRACE afd NOTRACE 


The TRACE directive directs the compijier to generate 
additional object code which facliltates tracing the fiow 
of the Program during execution. The TRACE directive Is 
ignored uniess the DEBUG_AIDS=TR parameter is given in the 
product cali command. 


The NOTRACE directive airects the compiler to not generate 
additional flow tracing object code. 


Minimum trace infermation will always be provided. See 
SECTION Feteleds 


Thea default for the compilation unit is NOTRACE. 
2e4e? DEBUG STATEMENTS 


DEBUG and NODEBLUG 

Source Input stetements that are to be compited oniy for 
debugging purposes are enclosed between DEBUG and NODEBUG 
directives. Enclosed scurce statements are compiled only 
If the DEBUG_AIODS=DS is given in the product call command. 
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20423 SEQUENCE CHECK 
SEQUENCE and NOSE QUENCE 


The SEQUENCE directive directs the compiler to check the 
Input source stetement sequence numbers for ascending 
order. 


If a sequence error occurss It wili be flagged with a 
warning dlagnostic. (See section 26204:2) 


The NOSEQUENCE directive directs the compiler to Ignore 
Input source stetement sequence numbers. 


The defauit for the compilation unit is NOSEQUENCE. 


The SEQUENCE and NOSEQUENCE Pines themselves are not 
checked for sequence. 


20429 OBJECT CODE LISTING 
OBJLIST and NOCBILIST 


The OBJLIST directive directs the complier to print the 
object code iilsting at this point. The NOOBJLIST directs 
the compiler to store printing the object listing at this 
point. The object code will appear in the object code 
part of the listing (see section 3.3.4). 


OBJLIST and NCCBJLIST act iNdcependentiy of LIST and 
NOLIST.j The default for the compilation unit is NOCBJLIST. 


2e4e10 STACKING COMPILATION DIRECTIVES 


PUSH (compilation directive) and POP 

The PUSH commanc will piace the specified compiiation 
directive on the top of the “directive stack". The POP 
directive will remove the top directive from that stack. 
This procedure will allow temporary aiteration of the 
local environment without permanently affecting the global 
environment. For exempie,s, if It is desired that a cailed 
common deck lists its name on the print files regardless 
of whether the entire common deck is being listeds then 
the folloning would be placed in the common deck: 


PUSH (LIST) 
comment inctuding common deck name. 
PoP 


225 PBR 


2e5el 


Parame 
Name 


BRIEF 


FULL 


COUNT 


FITLE 
WAIT 


NOWAIT 
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ODUCT DIRECTIVES 


The format of product directives icommands) must follow 
the set of language ruies and conventions of the System 
Command Languagee These directives frequently occur in 
products (often verious types of utilities) that are not 
compliers and ere thus listed seperately. The standard 
parameter names as described In sections 222042 and 2501 
must be used as applicable. 


STANDARD PARAMETERS 


These parameters occur frequently enough to warrant meking 
sure that all commands using them do so in the same way. 


ter 
Allas Parameter Description 


BR This parameter specifies that a brief form of 
Information is requested for displsey at a 
termine! or print file. It is a boolean used 
in cenjunction with the full perameter. The 
brief selection is used as the default. 


FU This parameter specifies that a full form of 
information is requested for display at a 
terminel or print flie-. It is a boolean used 
In conjunction with the brief perameter.. 


cou This perameter specifies a count of units (e.g. 
files records) associated with the command 
function. The default value Is one. 

F This parameter specifies the local file name of 
a file used as the object of @ command 
function. It is used when the flie Is not one 
of the specific files identified in section 
2020422 (@ege COMPILE, INPUT). 


WAI This parameter specifles the requestor should 
be placed in a wait stete if a request can't be 
immeciately processed {e.9. a file is busy). 

It Is a boolean used in conjunction with the 
nowait parameter. 


NOW This parameter specifies the requestor should 
not be placed In a wait state If a request 
cannot be Immediately processed. It is a 
boolean used in conjunction with the wait 
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parameter. The nowait selection is used as the 
defsuit. 


USER Us This parameter specifies a user 
identification. It is always the 3l—-character 
user and family names as specified to gain 
access to the system. 


PASSWORD PA This parameter specifles a 31-character 
password needed to gain access to an entity or 
to execute a function. 


UPON This parameter specifies the iocal file name of 
an output flie. It is used when the flie is 
not one cf the specific files Identified in 
section 2620402 (@eg. LIST» BINARY-OBJECT). 


LIBRARY LI This parameter specifies the local file nawre of 
adiibrery file (e.g. source library» object 
library). 


20502 STANDARD COMMANDS 


These commands are required» as a minimums If the functions 
described by the commands are inciuded In the utility. 
Utliities may optionaliy Include aliasas to the required 


conmand. 
Command Description 
QuIT This directive enables the user to exit» or get 


out ofs a utility. 
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Ali products will foliow a uniform set of conventions for 
generated outputs as specifled herein. Ali CYBER 180 
products will use the facilities cf the CYBER 180 Record 
Manager for such output. 


(341 RBECQUMENDED NUMBER. BASES 


The use of Rexedecimal numbefs on output produced by CY180. 
software must be controtied to promote readability. Ail 
products will follow the set of guidelines set herein. 


3elei STTUATIONS AND RECOMMENDED NUMBER BASES 


Address» Address Offset: Hexidecimal. When a length is 
specified In conjunction with an 
address or address offsets the 
length is represented in 
nexidecimal,. 


Dayfile information: Oecimal statistics, décimal 
resource timits. 


Gbhject Code Listings: 
Instructions: Hexadecimal (4 of 8 hex digits) 
Gperand fields: Decimai 

Branch Destination: Hexidecimal. The value is the 
instruction offset of the 
destination instruction rather 
than the reiative offset from 
the branch instruction. 

Instruction Offset: Hexidecimal. 

Core and File Dump: Varlous formats should be 
availables Including 
hexadecimal, ascii» integer » 
fioating point. 


Page numbers: Decimal. 
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The iogs treated In this Section are those maintained by 
the operating system. The OS provides interfaces to put 
ltems Into the logs and the SIS provides conventions on 
how to use these Interfaces and on the contents of data 
put into the logs. 


The set of logs is divided into two major classess ASCII 
and binary. The ASCII logs contain only ASCI I-encoded 
datae The binery logs may contain any type of data. 


The jogs include: 


— system tog (ASCII) 

~- job flog (ASCII) 

- account Icg (binary) 

- engineering tog (binary) 
~ statistic log (binary) 

~ job statistic log (binary) 


Ze2el ASCII LOGS 


Each ASCII log contains a set of records ordered by time 
of entry Into the loge Each record contains several. 
fields» some automatically provided by the logging 
mechanisms and some provided by the cailer of the 
machanism. The following fields are provided by the 
logging mechanism: 


- time of dey of the entry of the record into the Iog 


-~ origin of the message (commends program-issueds 
command from precedure, atc. -- that Is: catliers in 
OS rings way specify the message ofigin in the call, 
caliers in users rings may not and their messeges 
are always “progr am—-issued®). 


Tae system log has an additional system-provided fieid to 
identify the messsge issuing job. Also» each iog record 
contains a fieid for data provided by the program making 
the record entry. 


Except for certain operating system programs», the 
Interface to be used ty the OS and product set for putting 
messages into ASCII jicgs is that provided by the “message 
generator™,s a facility of the OS (see NOS/VE ERS). The 
message generator {fs given a status record that describes 
the type of message and any variable data to be "edited" 
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Into the message. The message generator: 


-~ finds the appropriate message skeleton in a library 
which Is in the current job library ilst 


~ edits the variable data inte the message 


~ Jogs the final message in whichever logis) are 
specified by a combination of: 


* destination specified within the message 
skeleton record 


* job option selection (e@eges “log only errors”, 
“log ail fatalis"», etc.) -- things such as 
mesSace importance level ere defined in the 
message generator cail. 


~ displays the message at a terminal depending upon 
job option 


The use of a message generator @ases: 

~ consistency of messages within and across products 

~ physical compression of message text 

~- extraction of message types for documentation 

- routing/suppression of messages based Upon message 
levels (eeges trivials fatais etc.) and upon user 
desire for only certain levels ("level™ or 
“Jmportance™ is specified in the message generator 
calls not in the message skeleton) 


- instaliation control over what kind of messages 
should appear Inf the system log 


Arbitrary user-initiated logging need not use the méssage 
generatore 


3e2e1.1 Systen_lLog 


In addition to the basic system—provyided fields, each 
system log entry contains a field identifying the 

pene coe ss job from which the message came or to which {ft 
appiles. 
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ae a we ee 


Sa2einive 


The primary purpose of the system iog is to serve as a 
repository for information regarding external system 
workload. That is» the work the system was asked to do 
vila commands and the high ievel responses of the system in 
regard to the commands. 


CINVENTIONS 

The system log conteins predominantly a subset of job log 
messages that ere of Interest to the installation. This 
normally Includes at least:. 


~ all system level commands (Suppifed by 05) 

- all commend completion messages 

-~ start cf each job execution (supplied by 0S) 

- end of each job execution (supplied by OS) 

- rerun of each job execution isuppliied by OS). 

- system identification (supplied by BS) 

- other infcrmation supplied by the OS tike datea,. 
hardware and software configurations and changes» 
deadstarts, recoveries, etc, 

The system tog should contain only Indications of the 
major changes in state of the system and of individual 
Jobs. 

The specific messages that should be routed to the system 
log in the defauit “as-shipped”" system will be determined 
on a case-by-case basis using these generai conventions as 
guidetines-. 

Note that since message destination (which tog(s)) 
Instructions are seperate from the message-issuing codes 
this determination does not involve code modification. 


See Job Log» Conventions for further guidelines. 
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Ze2ele2el PURPOSE 
The purpose of the job logy is to hold a trace of job 
execution. Information concerning the work requested and 
accomplished is recorded here. It provides a summary of 
the flow of the jobs preblams encountered and charges 
accrued by the job. 


Ze2ele2e2 CONVENTIONS 
Kaep tog messages simpi!e and short. Use the iogs for 
summary Information. Use list files or binary logs for 
detaliied cr repetitive data. 


Messages jionger than the listabie output "narrow" format 
are discouf aged. 


Simple completicn messages that convey no more Information 
than “it's done" are not to be put into logs. In a batch 
cases completion is obvious from the appearance of the 
next commande In an interactive cases the OS will see to 
It that the terminal user is notified of completion. 


Completion messeges that convey a smali amount of useful 
or interesting information are encouraged in order to 
enhance the “tive" appearance of the system. For examples 
"23 records sorted." or "Cycle 25 used.". Information not 
specific to the operation performed should not be 
included» however (ike CPU time for a compilation). 


Messages (at leest the non-brief mode ones) shouid have 
the general appearance of normal sentences. That iss they 
start with a capitai tetter» sere comprised of both upper 
and fower case fetters, and end with a period. When an 
“extended Message” of mofe than one line must be issued, 
each line should nots however, end with a perlods but each 
sentence shouid. This fanlliar sentence-type structure 
adds to the “corfortabie" feeling that we'd like our users 
to have for our system. 


Accounting and iow-level statistical and hardware error 
information is not to be placed into ASCII logs except by 
the 05S. 

Message~at~a-time "current status™ messages (like 
"compiling alpha... compiling betae..™”) are not to be 
Placed In logse The 0S will provide a meanS fof programs 
to post these kinds of messages. The current message witl 
be displayed at an interactive terminal when requested by 
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the terminal users. Pesting of these messages is 
encouraged. 


The message generator will suppiy product and message type 
Identification based upon the status record passed to it 
in acall. Precucts should not Include this Informetion 
in messages. 


When more than one datum is to be iOggeds try to minIinize 
the number cf messages Jines produced by putting more than 
one datum on a jilne. For examples issue: 


23 records sorted; Mé@r9e order 12 used; 14 insertions. 


father than: 
23 records sorted. 
Merge order 12 used. 
14 Insertions. 


(3.222 BINARY LOGS 


Binary logs are provided In order to allow the recording 
of log information in a compact form that is readabie 
primarily by programs. Each binary log contains CYBIL 
records ordered by time of entry into the iog. Each 
record contains severai fleidss some automatically 
provided by the iogging mechanisms and some provided by 
the caller of the mechanism. The following fieids ere 
provided by the icgging mechanism: 


- time of day of the eftry of the record Into the log 


~ the identification of tha job from which the record 
came or to which it applies (this field is not 
recorded in the job statistic iog) 


~ the origin of the record (system or non-system -- 
indicates only whether the caller is inside or 
outside system rings» not which product or which 
System agency --this latter information is given by 
the “Indicator of the type of record” fleid.) 


Fieids provided by the calier include: 


- Indicator of the type of record (¢€.ges number of FIN 
source stetements,» SRJs at end of jobs etc. --the 
indicator codes wii] be assigned and Managed in a 
manner similar to that used for status condition 
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codes as described in section 3.4) 
-~ varlabje data c€pending upon the record type 


Except for certesin operating system programs,s the 
Interface to be used by the 08 and product set for putting 
records Into binary logs is that grovided by the 
"statistics facility™ of the 0S. The statistics facility 
Is given a data record that describes the type of record 
and any varlabie information associated with the record. 
The statistics facility finds information about the given 
record type in e “table“. This “table" directs the 
statistics facility to do some combination of the 
following things: 


- add the veriable item(s) to counter (s) 


- tog accumulated counter values to a specified binary 
log or set of binery logs when a threshold counter 
value is reached cr when a certain time has elapsed 
since the last "put" to the iog{s) of the 
appropriate counteris). The set of logs is 
specified in the “tabie"™, 


—- simply ios this record in the "teble-specified" 
log(S) 


The use of the statistics facility for binary logging 
eases: 


- Installation talioring of what Is considered to be 
accountings performances etcte data. For examples 
site A may consider CPU time to be accounting data, 
while site B considers it a workioasd statistic and 
considers “number of statements compiled" to be 
acccunting data 


- optional routing of statistics to the job statistic 
jog (based upon user desire» but constrained by 
instaliation willingness -- via “table” 
information -- to divuige certain information) 


Since the statistics facility determines thea log into 
which a given statistic (for example, PIDFR data) is to be 
placea (based upon an installation and COC defined table), 
system and product impiementors should not be concerned 
with which fog(s) are used for “their™ statistics. This 
mapping wild be determined iater. 
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3e2e2e1 Agscount.Log 


—3e2e2e1.1 PURPOSE 

The purpose of the account log Is to hold accounting and 
biliing information. This consists of resources and/or 
services useds “who used them and "xzho" to charge. The 
account iog should be the only log needed for an 
installation to do billing. 


3222-2 Englinseriog.iog 


—Be2e2e2e1 PURPOSE 

The purpose of the engineering log is to hold Information 
regarding system hardware usage end errorse The 
engineering log should be the oniy log needed to perform 
hardware usage and error anlaysis. 


3022.3 Jiatistis.ies 


Ze2e2030e1 PURPOSE 
The purpose of the Statistic log is to hold: 


- detailed system workioad Information 


—- detajied system performance information (].aes the 
may the system responded to the workioad) 


Although some of this information 15 recorded in other 
logs» a separate log is maintained in order to: 


- keep other fogs relatively “clean™ or orlented to 
their own purposes 


~ allow possibly large amounts of data to be recorded 
in a compact binary form 


Ze2e20e4% Job Statistic.Log 
The purpose of the job statistic log is similar to that of 
the (giobal) stetistic toy. The global statistic log 
contains information regarding all jobs in the systems but 
may be read onty by priviieged programs / users. 
Individual userss however» may wish to see information 
that Ils availiatbie about their own jobs. The job statistic 
jog may be read by normal programs / users and contelns 
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Information regerding a single jobs» similar to the "scope" 
of the ASCII job log. 

3022265 Binary Log Conventions 
Avoid the use of character data. Since esch record type 
Is pre-defined by a CYBIL record type definitions there is 
seldom a need to describe the various data fields with 
keywords or the like. 


Message type Naming Follows the naming conventions 
described In SIS section 324. 


Use the binary logging facilities for PIDFR data. 


See the O35 ERS and the SIS Usage Statistics section for 
minimum tist of items to be logged. 


| Additional conventions wiil be added as design proceeds. 
323 LISTABLE_OUIPUT 
When a significant amount of information is to be returned 
to the users it is written to a “listabie output file. 
The standard format of such a file is described here. 
CYBER 180 Gutput Standard Is defined In terms of:. 
* Dutput Flie Organization 
° Listing Page Layouts 
° Page Header Format 
* Format of Esch Listing Typ® 
* Object Code and Debug Code 
3.361 LISTING PAGE FORMATS 
In the sections thet follow, the contents end format of 


the standard listings produced by CYBER 180 Products are 
defined in terms cof a vertical and horizontal layout. 
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Vertical layout is defined in terms of the first printable 
line of a form following top-of-form positioning by the 
printing devices This position Is defined as line 1 of a 
form and Is reserved for the first print line of the 
Standard listing header. The product is not responsible 
for the physical alignment of tine 1 relative to the 
perforated fold on fan-foid printer forms. This is the 
responsibility of the user on printers with vertical 
positioning carriage tape mechanisms Or the responsibility 
of the CYBER 18C OS Device Software on printers without 
vertical carriege mechanisms. 


When the last printable line of a fOrm hasS been written, 
the product wlll reset the page iine counter to 1. When 
the page JIine counter is equal to ls» the next print line 
written Is preceded by a standard listing header with a 
top-of-form code in the first chsracter position of the 
header print record. The product is not responsibie for 
the physical alignment of the iast printable line reiative 
to the perforated fold on fan-fold printer forms. 


-3e321.2 Eormat_Atircibutes 


Each product must obtain the cutput file attributes from 
the operating system at the time the file is opened. 
These attributes include print modes page widths connect 
status» page formets and gage tength. Vertical and 
horizontal print density have operating system defined 
defaults which may be Changed by the user. 


Dutput Flies may be either continuouss which has a tine 1 
position but does not have a Jast tine positions or 
paginated ({non-continucus)s which has both a line 1 
positions and @ iast tine position. Continuous fors 
specification files are intended for users using 
interactive terminals (dispiay or hard-copy) for iistabie 
output. Paginated (or “fan-foid™) listings are intended 
for users using line printers for listable output. 

For paginated files» page Length minus the number of fines 
of header determines the avallabie lines per page. The 
operating system provides a (default) standard paye length 
of 66 lines per page at 6 jiines per inch 

vertical print density. This provides an 11 inch form 
length. Print mode specifies whether or not the paginated 
fiie ts “burstable™ or "“"non-burstable™, with 
"non-burstable™ being the default. 
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A continuous form file is detected by checking the flie's 
attribute page format. Connected files will defauit to 
continuous form modes but users may override this by 
specifying a pase tength for the connected file. 


(34321.22.1 CONTINUOUS OUTPLT FILE 
When formatting iistable output for a continuous forms the 
product uses a standard tripie-space code in the first 
character position of the line 1 output record (usueily 
the first line cf the header) to achieve top-of—forsm 
positioning» Products will reformat listings for terminal 
users when resulred by this standard. 


Each type of listing (source iistings attribute listing» 
etc.) is preceded by a triple-space and the usuai header 
line(s)s» but there Is not pagination as such. 


3e3e1e2e2 PAGINATED OUTPUT FILES 
When formatting output for paginated listings» the product 
uses a standard top-of-form code in the first character 
position of the tine 1 print record (usually the first 
line of the Reader) to achieve top-of-form positioning... 
In burstable ilsting modes each type of listing produced 
by the product (source listings attribute Jistings etc.)) 
bagins at a top-of-form position. in non-burstabie mode 
(sometimes referred tc as "paper saving" mode)» each type 
ef isting Is preceded by a triple=-space and the usual 
header Jine(s) if “proper space” remains on the current 
pagee “Proper space™ is defined es 6 pius the number of 
header iines (insuring that at least 3 iines of output can 
be placed at the bottom of the page); if "proper space" 
does not remains the triple space Is replaced by a 
top-of-form. The source listing always begins at 
top-of—forms, and user-specified page ejects (via 
compilation directives) always result in a top-of-fors 
position uniess the tisting Is already positioned there. 


3632163 Standard Carriage_Controi Codes 


Carriage Control characters that ere used should be 
restricted to the following set: 


Character Action 
blank Spece verticaiiy one ilne then print... 


0 Space verticaliy two lines then print.. 


. 3-12 
CYBER 180 System Interface Standard 

| 86/02/04 
3.0 OUTPUT 

3e3e0ele3 Standard Cerriage Control Codes 


- Space vertically three iines then print. 


1 Eject to the first line of the Next page 
befcre printing. 


+ No edvance before printing; allows 
overprinting. 


This set represents the full extent of compatibility 
between current COC usage and the proposed ANSI standerd. 


Under NCS 180» horizontéi print density and 

vertical print density are File attributes that the user 
may modify. The NOSs NOS/BE carriage controi codes § and 
T will not be used to set or clear the 8 iines per Inch 
mode. 


It wili be necessery to make some provision for selection 
of print density when NOS 180 print files are to be 
printed by NOS or NOS/BE. The first release of NOS 180 
wlll depend entirely on 170 state for print files. 


3.3.1.4 Horizontai_Layout 


Hor}izontal layouts are defined for the standard wide format, 
that iss 132 columns. Assuming a default density of 1¢ 
inches per seconds 132 columns uses 13.2 Inches of the 
Standard 14-inch line printer paper width. 


Products are also required to support two terminal formats: the 
Standard “wide format", 132 columns» and the standerd “narrow 
format", 80 columns. Formatting for other line widths in 
addition to the standard terminal iine is permitted. Aji 
formats other than the two standard formats are referred to as 
“other formats". 


The first character position of arn output record Is interpreted 
by the output device software as the vertical positioning 
control character and is never printed or displayed. The 132 
character positions following the first character position of an 
output record contain the characters to be printed or 

displayed. Therefores the character in the second positon of 

the output record is printed or displayed in the first position 
of the output tine. 
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3630125 Standard Listings teader 


Ali CYBER 180 Products wili uSe a standara 2 line page 
header format on all listings produced by the products. 


Through this sections date and time flelds conform to 
standards defined in section 4.1. 


3230166 OTHER FORMATS 


If the line width specified is other than 80 or 132 

the heading will be mapped to one of the two standard 
listing headers. Other cutput will honor the actual fine 
widths, unless specifically column orlanted throughout the 
line fas opposed to column oriented for the first portion 
and open ended for the last portions such as source}. 


Line 1 of the common page header contains the follosing 
fields (field definitions are in COBOL format): 


System Name x (8) Operating System name. 


Product Name x(8) The tlonghand form of the 
product names 1.@s» FORTRAN» 
FMU, BASIC» etc. 


Product Version 9.99 Product version number. The 
number after the decimal 
point is shown teft 
Justifieds i.e. 5eis not 
5.01. This number is updated 
at the product source code 
level by the responsibie 
development organization for 
each new version release. 


Product Level 99999 Product modification ievel contsined 
within the product itself. It is in 
the form YYDOD representing the julian 
date when the product was compiled. 
This number is updated by the bulid 
procedures for each new update reiease.. 


Listing Neme x (14) Name of the particular 
listing being produced. The 
acceptabie listing names are 
defined in the following 
sections which define the 
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format of each listing type. 


Module Name x(31) Name of the source module 
belng complied or the name of 
the input file being 
processed. The moduie name 
Is obtained from the module 
identification statement 
provided within the languages 
ors the default name provided 
the product when an 
identification statement Is 
not used. This name need not. 
appeer In the first page 
header if unobtainable. The | 
name will appear teft 
Justified within the fieid if 
shorter than 31 characters. 


Date: x(18) Date at the time the first 
header was written (iisting 
Page Number reset to 1). The 
date is obtained from the 
CYBER 180 OS using a standard 
Program Management request. 
The date format will conform 
to the standard glven in 
section 41+ 


Time: x412) Time of day at the time the 
first header was written 
{fisting Page Number reset 
to 1). The time Is obtained 
from the CYBER 180 OS using a 
standard Program Management 
request. The time format 
will conform to the stendard 
given in section 4.1. 


Page Number *PAGE*® 2229 #£=Integer number generated by 
the product starting at 1 and 
incremented by 1 for each 
page header written for a 
compilation unit. The page 
number is reset for the first 
page header written for a - 
compiiation units This field 
is omitted from the standard 
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3.2322 FORMATS 


Two logical 


products: 


header when a continuous form 
is specifled. The two parts 
are always separated by sone 
bianke 


line width listing formats are generated by 


- Page Formatted lines of 132 characters 


~ 80 Column Formatted Lines of 80 characters 


3e3020e1 Wide Format.(132_csalumns2 


A standard header will be written at the top-of-fora 
position of a listing whenever the page line counter is 
reset to 1 except when a continuous form is being 


writtene 


A standard header will be written only at the 


beginning of a listing when a continuous form is 
A specified page width of 132 or greater will 
result In the following heading jiine. 


specified. 


FILE CONTENTS LIST - WIDE FORMAT 


Columns 


Columns 
Columns 
Columns 
Columns 


Columns 


Columns 
Columns 


Columns 


1-14 


16-46 
48-53 
55-(54+n) 
(564n )-(594n) 


(614+n)-89 


91-108 
110-121 


123-132 


Listing Name or Columns 1-46 
program name 


Module Name 

System Name 

Product Name (length=ns n<24) 
Product Version (fength=4) 


Product Level (length=5» biank 
filled) 


Date {right justified} 
Time {right justified} 


‘PAGE and Page Number fright 
Justified? . 


Alt unspecified columns contain blanks. 
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FILE CONTENTS LEGIBLE - WIDE FORMAT 


Columns 1-14 Listing Name or Columns 1-46 
program name 

Columns 16-46 Module Name 

Columns 48-53 System Name 

Columns 55-78 Product Name 

Columns 80-83 Product Version 

Columns 85-689 Product Level 

Columns 91-108 Date {left justified} 

Columns 110-121 Time {left justified} 

Columns 123-132 PAGE and Page Number {left 
Justified} 


323.202 Narcew Eormat_(80.Coiumos2 


The product wili reformat the standard page format for a 
80 character line. <A physical output line format 
greater than the specified line size may be right-end 
truncated by the product to the required specification. 
The excess cheracters will appear on the next line. A 
product mey choose to reformat narrow listings within 
the provisions of this document. 


The header format {on terminal formatted listings} 
consists of two consecutive lines containing the fieids 
defined above in the following positions on lines 1 and 
jines 2. The PAGE and Page Number fletds are optional 
for continuous files. 


This information wlil appear within the following column 
positions of the first print fine (Product Names Product 
Versions and Product Level are left justifieds seperated 
by one blank column): 


FILE CONTENTS LIST 
Line l 


Coiumns 1-14 Listing Name 
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Columns 16-46 Module Name 

Columns 48-65 Date fright justified} 

Columns 70-80 Page {right justified} 

Line 2 

Columns 1-6 | System Name 

Columns 8-{7-n} Product Name {length=nsn = 24} 


Columns {9 +n} - {12+n} Product Version {length = 4} 


Columns {144n} = 42 Product Level {fength=5» biank 
fill} 
Columns 48-65 Time Cright justified, 


Jeft biank padded] 
FILE CONTENTS LEGIBLE = 80 Column Format 


Line 1 

Columns 1-14 ‘Listing Name 

Columns 16-46 Module Name 

Coiumns 48-65 Date {ieft justified} 

Columns 70-80 Page {left justified} 

Line 2 

Columns 1-6 System Name 

Columns 8-{7-n} Product Name {iength=n». n=24} 

Columns (94+n}-{12+n} Product Version Clength=4} 

Columns {(14+n}-42 Product Levei fiength=5 bi ank 
FILis 

Coiumns 46-65 Time Cieft justified, 


right bdbiank padded] 
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“30323 SOURCE LISTING FORMATS 


The Following standard appiles to compilers,» assemblers 
end interpreters. <Assembiars may optionaliy Insert binary 
information at the feft cof the source statement. Page 
ejects mey be suppressed for subsequent listings of each 
module (@ege Map» Cross reference) if the source listing 
Is short (e.g. 1/2 a page or less). 


The number of records in the source file should be the 
same as the number of source lines in the source list. 
Therefores nuill records should be mapped to all. blanks. 
{See section 2232262) 


34363-1 Siandard.usader.Contents 


Every printable source listing contéinsS the foliowing text 
in the Listing Name fleld of the standard listing header: 


SOURCE tIsT oF 
--14 characters-- 


A standard source ilsting header will be written at the 
next top-of-foram position whenever the page tine counter 
is reset to 1. Onty the first source tisting Reader will 
be written on s continuous form. 


30323-2 ITILE Lines 


When source embedded TITLE or SUBTITLE directives are 
processed, the page line counter is reset to 1 and e 
Standard header is written. The titie text is printec 
beginning in column 25 and ending in column 132 of the 
line immediately folitowing the first Jine of the standard 
header. The titie tines are foilowed by a biank line. 


Standard hesder -- line 1 
titie text -- line 2 
subtitie text -- Ilne 3 - 11 (If any) 
blank -- fine n 


n may take the vatue 3 to 12» depencing upon the 
presence of a subtitie fines. 


When a source fisting is being formatted for a continuous 
forms the titie tine is simply preceded and foilowed by a 
single biank tine. 


If a SUBTITLE occurs without a TITLE» a blank fine Is 
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placed In the postition which would have been occupied by 
the TITLE. 


When the source input module does not contain a TITLE 
directives two blank tines immediately follow the second 
line of the stendard tisting header. 


(3436303 Hide Foruat 


The actuel source statement listing begins on the Iine 
foliowing the blank line foliowing the headers or tities 
If present. Each source jisting print line contains the 
following optional fields: 


Offset z(8) A zero suPPressed hexadecimal 
number (see section 3.1) giving the 
byte offset in code section of the 
first instruction generated for the 
listed source stetement. If this 
field is supported, it is selected 
by the list option 80. If 
selecteds the field must be 
supplied for ali source listing 
fines. 


Input Line 
Number Z{10) A numerics zero suppressed number» 
up to 10 characters In langths 
alijocated to the source line. See 
section 223-6 


Left Statement 
Attributes x (4) lenguage dependent attributes. 


Right Statement 
Attributes x (4) Compiler dependent attributes. 


The Source Record 
is a required field 


Source Record x(132) Up to the first 132 characters of 
the Input source record. If the 
source fine is tess than 132 
characterss this fleild is fteft 
justified. Source Code Utility 
{SCU) tdentifiers are contained 
within this fleids, if they exist. 
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If ail fleids were present In a source listings column 
positions would be: 


Columns 1-8 Offset — 

Columns 10-13 Left statement attributes 

Columns 15-24 Line number 

Columns 26-125 Source (Including SCU 
identification when present) 

Columns 127-130 Right statement attributes 


If an optionai flelid is not used the remaining fieids will. 
be adjusted to the left. 


When the source record (26-125) includes SCU 
Identification information the following column positions 
will be adhered te For the source record 


Columns 26-105 Source 
107-125 SCU identifier. 


The fleids should not be changed (mixed) between 
successive uses. Once the fields desired are estabiished 
they must remain unchanged. 

Existing fields before and after the source record may be 
blank. If the source record overflows an additional dine 
Is written within the source record field. In this case 
the right attributes fleid of the first line contains 
¥,.2! as the first three characters and the rest of the 
field and offset field are biank. The overfiow Jine 
contains blanks in the fine number fleid and the remainder 
of the source record left justified in the source record 
fieid. The right attributes field conteins the 
information which would otherwise have appeared in the 
first linee 


(323.234 Narcow Format 

The source listing format written on a terminal forsatted 

listing consists of one or more output tines for each 

Input source recorde 

The first line consists of the following flelds: 

Line Identifier Numeric right Justified leading 

zeros suppressed. Optional 
varlable width field up to 10 
characters. 


Source Record The sOurce record field size is 
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dependent on the file attribute 
maximum record iength and the size 
of the line number field. 


A singie biank separates these two fields. 
The source recora fleid size is dependent on the file 
attribute maximum record leagth. 


If the source record is longer than the Source Record 
fleld then an ecditionsi Line is written. The lines sre 
printed with the same format conteining blanks in the Line 
Number field and the remainder of the source line 
left-justified in the Source Record field. 


32324 OBJECT CODE LISTING FORMAT 


This is the format for jiisting lines of object code 
eroduced by the compilers at the users request. 
Assembiers list their source lines formatted as submitted 
from the input file. 

The object code listing shaili take cne of two forms. The 
first consists of lines describing each CY180 instruction 
embedded in the source listing anc» as far as possible, 
foliowing the same line from which the code Is generated. 
The object code tine shail conform to the standard defined 
below. A group of object code listing lines shail be 
preceded and followed by a blank line. 


In the second forms, the tines describing the obJject code, 
aiso conforming to the standard defined belows are 
coliected into a separate Jistings the “object code 
listing™ which shall conform to a page format common to 
the listings eprcoduced by ali compliers. This is defined 
as follows. 


Object code jistings consist of instruction descriptions 
and comment tines. 


Instruction Description 


With the exception of BDP Instrucionss each instruction 
emitted Is described by a single print tine optionally 
praceded and/or followed by comment lines. The 
Instruction description will contain the following fields 
In the foilowing orders beginning In column 2 of the 
listable output. 


Offset Z(8) A zero suppressed nexadecimai number 
{see section 3.1) giving the byte 
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offset of the instruction relative to 
an impi€mentation defined base. This 
base shall be the same base used in 
the offset fieid in the source fine 
(if provided.) 


X(1) 


Input Line 
Number ZZZZZ9 The number of the input tine for which 
the code is belng generated (as far as 
is practicable). 


x(2) 

Binary X(Z0) An 4» 8 or 16-digit hexadecimal number 
(adjusted to the left) representing 
the binary bit pattern corresponding 
to the generated instruction or data. 
For readability the suggested form ts 
to arrange the numbers in groups of 4s. 
seperated by blanks. The 4 and 8 
digit numbers are followed by bianks 
to complete tie fFleid. For narrow 
formats this fileid wil! not be present. 


X(2) 


Label X{31) A 1 to 31 aliphenumeric character 
string identifying the Instruction 
jabel as defined for the CYBER 180 
assembier. The iabe!l field can be up 
to 31 characters in fengthe It can be: 
used in an implementation manner in 
conjunction with the comment field. 


X{(2) 


Instruction %X(10) <A character string identifying the 
B(3) instruction and its operands. The 
X(21) mnemonics to be used are those defined 

for the CYBER 180 assembier. The 
mnemonic identifler only may be offset 
by 2 or 4 spaces to distinguish 
Particular instrucions ofr instruction 
sequences. {(@ege to identify code 
generated out of sequence with the 
scurcee) Operands are specified in 
the order defined in assembler 
specification which appears in an 
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Appendix (to be supplied). As shown 
in the format descriptions the 
breakdown of the instfuction is as 


follows: 
MNE MONIC X10) 
X{3) 
OPERANDS xX{21) 
X (1) 
Comment X{(25) AN implementation dependent fieitd 


typically containing user variabie or 
label identifiers register use 
cress~references. 


Narrow Format 


The narrow formset and 80 Column Format consist of the 
offsets iine numbers tabel» mnemonics operands and 
concatenated fields. The binary field will not be 
present. if the listed tine exceeds 80 columns the 
line wili be continued on the next fine (called 
“foiding™"). Fer PN other than 80» the actuai width 
specified willl te honored; excess information will be. 
foided. 


Bdp Instructions 


These are described by a iine formatted as aboves folfowed 
by one or two descriptor descriptions. These are similar 
to the Instruction tines except that the mnemonic field is 
blank and the operand field contains a descriptor in the 
form defined by the assembier specification. 


Comment Lines 
These are used to convey more information than can be 
accommodated in the comment field of an Instruction 


description. They consist of a comment field as defined 
for the Instruction description. 


3.3.4.1 Siandard Yeader Contents 
Every printable object code jJisting contains the following 
text in the Listing Name field of the standard listing 
header= 


OBJECT LISTING OF 
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--20 characters-- 


A standard object listing header will be written at the 
next top-of-form position whenever the page iine counter 
Is reset to 1- Oniy the first object iisting header slit 
be written on a continucus form. 


3.3.4.2 Standard Jostruction Moesonicas 


The instruction menmonics used by the Compilers will be 
those of the CYEER 180 assembier. 


34325 ATTRIBUTES LISTING FORMAT 


A common format for the Attribute/Cross Reference listing 
Is defined here. It is useabie by ef] currently planned 
languages for the Cyber 180 and provides enough 
fiexibility tc tailor portions of the listing to 
Individual jianguage needs. 


The content of the Attributes Listing will vary slightly 
depending upon whether Cross References were selected or 
nots but the essential format wlll be the same. If the 
user selects both attribues and referencess the normal 
format will be used. When references are not setecteds 
the heading will reflect the differences but the format 
will not vary. If references are selecteds tut not 
attributes,» then some of the attribute information 
provided wild not be listed» providing some additional 
space for references on the line. 


323.501 Standard veader Contents 


Every printable attribute listing or attribute/cross 
reference listing contains the following text in the 
Listing Name field of the standard listing header: 


ATTRIBUTES CF 
---14 charecters---- 


If no attribute list is selected (cross reference selected 
oniy) the following text is placed in the Listing Neme 
fieid instead: 


REFERENCES CF 
~--14 characters---- 


A standard attribute iist header wili be written at the 
next top-cf-form position or following a triple spaces as 
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specified by sections 3.2321.221 and 323ele2e2,s and 
whenever following page breaks occur. Oniy the first 
attribute list header will be written on a continuous fora. 


The standard header is followed by «6 biank line and one or 
more iin@s contesining the attribute/cross reference 
listing heading. This consists of the field descriptions 
as defined In the next sections» separated by one or more 
blanks. Numeric flelds in the iisting are right-aligned 
with the right-hand side of the description; character 
string Flelds ere aligned on the left, where appropriate. 
Some of the field descriptions may be split between two or 
more lines if required, os omitteds if necessarys as 
indicated below. 


3-325-2 Wide Format 


The Jisting is wade up of entries describing the objects 
defined in the source program. Eech entry consists of a 
definition lines folicowed by one cr more extension lines 
if required. The definition line gives the line in which 
the object was ceclared (or first referenced if iImplicitiy 
declared), the identifiers and attributes. Extension 
limes are used if there ere more attributes than can be 
accommodated on one tines and to hoid references if. 
selected. If both attributes and references are selected» 
the references selways begin on an extension line by 
themselves. 


The dines contain the fields described in the table bellows 
in the order specified. The tabie also contains the fieid 
description to be piaced In the tabie heading. The finai 
section of the dine (for host supplied free form 
attributes and the references) is continued on extension 
lines es necesser y. 


Entries occur In alphabetical order with a biank tine 
inserted between groups of identifiers starting with the 
same character. Multiply defined identifiers are 
consecutive In order of increasing ievel of nesting or In 
order of occurrence of biock. 

Variable format fleids are optional. They are in the 
indicated order if used, otherwise the fieid is not 
present. The sizes for the given fieids are maxinua width. 


ATTRIBUTE/CROSS REFERENCE LISTING FIELDS 


Fixed Format: 
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Fiheid Heading Size Meaning 


identifier IDENTIFIER X(31) Tre identifier of the entity. 
The name appears ieft justified, 
blank filled. 


biank X(1) 


dafinition DEFINED Z(5) The source line nUmber in which 
ON LINE the entity was defineds or {for 

languages with Implicit 
definitions) first used. It may 
extend into the identifier field 
if targer than five (5) digits. 
The second fine of the heading 
~ON LINE- appears oniy in the 
wide format. 


blank M1) 


size SIZE unit x3) Size of the entity» In units» 

defined by the host (elther bits» 
bytes» or words). The units of 
the size of the entity witl 
appear as “BIT™"»s "BYTE™,s or 
"WORD". Abbreviations are BIT», 
BYTs»s WROD. Normally the fields 
for size unit combination will be 


size 2(8) 
blank X{1) 
unit X¢4) 


if the size fieid exceeds 8 
digits» then the flieids will be 


size Z(10) > 
unit x(3) 
Special case: 


If size units Is no-size, then 
the size field Is allowed to be a 
signed integer (64-bit). This 
will be right justified under the 
SIZE titie if possibie. If it is 
too targes it “grows™ to the 
right. If it Is so targe es to 
grow into the TYPE fields the 
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TYPE fieid is pushed to the 
right. This is possibile beceuse 
the LOCATICN field ts undefined 
if the SIZE units are no-size. 


blank X¢2) 

type of TYPE X(10) The type of the entity being 

entity listed. Chosen from the list in 
Section 3232504213 If the host 
wishes further qualificaticns 
listed they appear in the 
attributes list. 

blank x(1) 

Yocation LOCATIGN Minimum The location of the entitys 

SEC+OFF x{6) where “"SEC*® Is the section neme 


of the section containing the 
data for the identified 
references and “off" is the 
offset te the beginning of the 
section. The section names sare: 


$LITERAL The s@ction 
containing literal 
constant data. 

$S TACK The section 
contsining variables 
that are silocated 
on the stack when 
the containing 
procedure is called. 

SPARAMETER A subset cof the 
$STACK section 
containing parameter 
list variables 
elilocated on the 
stack by the calling 
procedures 

$STATIC The section 
containing variables 
that are staticaliy 
allocated, are not 
in commons and are 
not in an explicitiy 
named section. 

SREGISTER Variabies not 
belonging to eny 
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memory section but 
existing oniy in a 
herdware registers 


SBINDING The binding section. 

SBLANK Biank (unnamed) 
common. 

CYBS DEFAULT 

HEAP The system heap, 


Code section names will be set to 
the name of the procedure the 
section represents. User defined 
names of section and user 
declared common biocks wild siso 
be specified in full fup to 31 
characters). 


when a “sec"® name is too ferge to 
fit into the default field size 
allocated, the entire name is 
printed» expanding to the right. 
A line feed and re-alignment. 
"back" to the next listing field 
allows continuation of cross 
reference data generation. for 
narrow format (section 3.3253)» 
if the “sec"™ name does not fit on 
the lines it will be put on the 
next line by itseifs then the 
rest of the map wild continue 
following a line feed and 
re-alignment to the next flieid. 


Variable Format 


Field 


biock 


blank 


For nerrow formet listing the variable format fields» 
continue on a new line beginning In column 15 and 
extending to column 80. For wide format listing the 
variabie format fleids continue on the same fine beginning 
in column 75. 


Heading Size Meaning 


number BLOCK Z999 Specifles the block or subroutine 
in which the object was defined. 


Xt2) 


nesting NEST ZZZ999 The nesting level of the 
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level LEVEL declaration of the entity if a 
block-structured language. If 
the host is not a block 
structured languages the nesting 
level is omitted. The second 
line of the heading - LEVEL - 
appears oniy in the wide format. 
bi ank x2) 


containing CONTAIN OR K(31) The name of the containing or 

entity DECLARED IN quaiifying entity. Blank If the 
entity Is not contained or 
qualifled. The "contained 
wmithin™ form is for arrays and 
structures. The "declared in" 
form is for local variables. The 
entire heading is on one line. 


biank X(2) 


basic ATTRIBUTES X{12) The “basic attribute” of the 

attributes entity (entry» externais, etc.). 
chosen from the list In section 
Zedece4ele Biank if 
non-appliiceble to the entity. If 
there are no optional fieids and 
the basic attribute ts not 
presents the whole fine Is 
omitted in narrow formate 


user {no heading) free Other host defined attributes 
attributes field Separated by commas. These 
start- attributes begin on a 
ing on separate line beginning with 
a sepa- column 54 for wide format and 
rate column 15 for narrow format 
line distings. Each definition 
specified by the host is piaced 
on one line if possibile» 
otherwise each that overflows 
starts anew iine. If the 
definition doesn't fit aione»s it 
is broken at a blank. 


references REFERENCES Z(6)Xi2) References on the identifler 
For combined line begin at column 54 one 
map» subheading the listing In narrow format 


will be the first iine has two 
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references. Subsequent 

“REFS, lines start In column 15 

starting on and have six references per 

aseparate lines In wide format ail 

line. lines stert in column 54 and have 


& references per line. For mixed 
mode iistingss see discussion 
below. 


The format for references is a six digits right 
Justified» biank filled integers followed by an 
optional siash (/)» followed by quaiifying ietters 
chosen from the jist In section 3.342524:3. This 
combination Is followed by a blank, 


In mixed mode (combined attributes and references), 
both the attributes and references are handied as 
described above,» except that the first reference line 
has a subtitie -REFS- placed at its left. The subtitie 
-REFS= is piaced In columns 9-13 on the narrow listing 
and in columns 48-52 in the wide listing. 


Since the user may select the attributes listing 
separate from the references ilstings the following 
changes occur when both are not selected together. If 
attrisutes cnly are selacteds, the references are not 
listed. If references oniy are selecteds the 
identifiers iine number and references fleids are used 
and the references begin at the end of the first line» 
not on an extension tine. 


3232523 Narrow _Eormat 


The narrow format tisting will have the same format as 
the wide listing with the exceptions noted in the 
describitions in section 3.32522. and with the 
exception thet the attributes end refernces fietds will 
continue on an extension iine teginning in column 15 
and extending to cclumn 80. 


3030504 Standard Eleld Values 
303050421 ENTITY TYPES 
Each é€ntity is essigned a basics cross-language type. 
These appear in the “Type” field as one of the foliowing: 
TYPE ABBREVIATED FORM 


Simple vary» VAR 
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Arrays ARR 
Structures STRU 
Member» MEM 
Conditions COND 
Constant» CONS 
Type» TYPE 
DEF» DEF 
Programs PROG 
Module MOD 
Procedures PROC 
Functions FUNC 
Label» LAB 
Switch» SwCH 
Files FILE 
Formats FMT 
Paragraphs PARA 
Sections SEC 
Impl name» (for implémentor name) IMPL 
Groups GRP 
Alias ALIA 
Error ERR 
Attr name» ATTR 


Each host need not support ail types of entities on this 
lists but shoulda define a consistent mapping into a subset 
of the above. The final entry ("Error") should be used 
for entities whose definitions contain syntax errors 
sufficient to prevent the compiler from determining the 
user's intentions. 


3ede5e%e2 BASIC ATTRIBUTES 
This fieid contains attributes basic to the entity 
dafinition which ere exclusive of one another. If the 
entity does not fali into one of the following catasorles 
of attributess then the fileld is iteft biank. These are: 


Attribute Abbreviated Ferm 
undefined UNDEF 
unreferenced UNREF 
EntryPoint ENTRY 
External EXTRN 


None (field Its blenk) 
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3032504.3 REFERENCE TYPES 
The stenderd reference type abbreviations wiil be: 
M the entity was set (modified), 
(blank)s» the entity was used {slash is also omitted) 
A the statement defined an entity attributes 
s the entity was a subscript or index, 
I the entity (usualiy a file) was referenced in 
an 1/0 statement 
R the entity was reed into {ors if a files was 
reac) . 
W the entity as written from (ors if a files was 
written) 
Pp the entity was used as en actual parameter 


For ali Jistings containing references there is a legend 

of the possible reference types and their one character 
abbreviations at the bottom of each page. This legend is 
right justified and takes the form abbrev = full names eoes 


For example: M=modify» A=attributes S=subscripts 
I=I/0 refs R=reads W=writes, P=pareme 


Each host may ctoose to use the entire set or a subset 
thereof, tut It is hoped that most hosts will use the 
entire set. 


32326 DIAGNOSTIC LISTING 


The diagnostic listing for compliers» assembiers>» 
interpreters, etc.» consists of diagnostic messages. 
Diagnostics are listed in either of two modess at the 
host's choice. The first method lists ali diagnostics and 
a diagnostic sunmary at the end of the iistings following 
the Attribute/Reference fist (If selected). The second 
method lists syntax diagnostics in the source listing as 
they are detecteds with later (non-syntax) diagnostics and 
tne diagnostic summary being listed at the end of the 
Attribute/Reference fist. If the first method is 
selecteds the host may also choose to have the jiocation of 
the diagnostic occurrence flagged in the source jJisting 
(by means of a caret symbol under the offending column). 


When compilation occurs with zero diagnostics a diagnostic 
summary wil! be produced consisting of the singie tine *NO 
ERRORS! . 
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(3232601 Standard peader Contents 


Every printable error tisting/summary conteins the 
following text in the tisting name fieid of the standard 
fisting header: 


ERROR LIST CF 
~—=—14 characters---- 


A standerd error tisting header will be written et the 
next top-of-form position or following a tripie spaces as 
specified by sectionS 3e3ele2e1 and 3e3eie2e2s and 
whenever a subsequent page break occurs. Only the first 
error listing header Is written on a continuous foram. 


3036602 Standard Diagnostic Listing Eocmat 


All diagnostic fistingss whether grouped together at the 
end of the other fistings or printed intermixed with the 
source iilsting will have the same basic format. When 
groupeds they will be fisted In source line/statement 
column/diagnostic number ordere When grouped and the 
diagnostic number is not being printeds they will be 
Jitsted in source tine/statement column/order of issuance 
order. When printed intermixed with the source listing» 
they will be printed in the order the host detects them, 


Coiumn positions are specified for the case where ail 
fleids are useds and remain the same if an optional fleid 
Is not used. 


Column 

Position Contents Format Meaning 

1-9 bevel X(5) error severltty level of the 
diagnostic 

11-17 line nre Z16)9 source statement number on 
which the error occurred. For 
diagnostics intermixed with 
the source listings this field 
contains *ERROR*. 

22724 Glage NOse 1299 diagnostic number of the error 
(assigned by the host). This 
Field Is optional. 

26-28 COL X(3) The abbreviation for the word 


column in intermixed mode. If 
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the column number field 
contains zeros *COL’ fs 
suppressed. iIn grouped mode 
this fieid contains the column 
number described belons and 
that field is blank. 


30-32 COle. nO» ZZ column number In which the 
error was detected. Blenk if 
not applicable. In grouped 
mode the column number is 
present in the col (26-28) 
flela and the column number 
field is biank. 


34-e01 text the diagnostic text idefined 
by the host). Each word 
within the text is separated 
by one space and the line Is 
fliiled es required. Extension 
lines begin with the text . 
position through the end of 
the tines single-spaced. In 
intermixed modes the *ERROR* 
indicetor is re-Issued on 
extension tines. 


Diagnostic summary for products that use diagnoStics 
Intermixed with source Shovld include a page iilst of pages 
with dlagnostics. 


3030663 Standard Digunostic.iummaryEFormat 


The diagnostic summary will follow the disgnostic iisting 
for grouped diegnostics,s, or stand-alone for Intermixed 
djagnostics. ir either case it provides the user with a 
Summary of diagnostics detected and listeds as directed by 
the EL parameter. 


There wiil be an diagnostic summary tine for each ievel of 
diagnostic detected during the complliation. If no 
compltiation errors (at any level) were detected» then that 
¥s noted. The foilowing format will be used for ail of 
the summary lines: 


columns 3-6 REE Summary line Fiag 

columns 9-14 Number of diagnostics of a 
given category» in the format 
Z(5196 
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columns 1lé-e01 Texts in the format "aaea 
diagnostics", where aaaa is 
the category being 
summarized. If the 
diagnostics were not listed 
{due to EL setting) then 
"Cunlisted)" Is appended to 
the message. 


If only one diagnostic at a given level was issueds the 
word "dlagnoOstics”™ will be "diagnostic" in the messages. 


32327 COMPILATION OPTIGNS 


The compilers will produce one or more iines of output to 
Indicate which contro! statement options were selected for 
this compiie (either by default or explicitiy). The 
format cf this line will refiect sectlon 2.2 of tals 
standard» This iine will appear efter all other listings 
for each moduje. It is produced whenever any list option 
's selected and not produced for LOG=NONE. 


3-4 ERROR MESSAGES 


This section describes conventions for ail ASCII error 
meSSages. This includes log messages {to system and Jjob 
fogs)» Interactive messages» and error messages written to 
the OUTPUT or other files (reference logs» section 3.2). 
The conventions include the use of the Message Generator» 
massage Identifications and meSsage wording. 


32401 CONDITION CGDES», EMBEDDED PRODUCTS» AND MESSAGE GENERATION 


3e4e1.1 Condition. Codes 


A summary of the NOS/VE status record fieids Is noted 
below. The NOS/VE ERS should be referenced for a complete 
dascription of the status record and the Message Generator 
interfaces. All productss Including products embeded in a 
host product» shali adhere to these conventions. 


Normal - A boolean which has a value of FALSE if a request 
could not be processed correctiy and TRUE if it has been 
processed correctly. 


Condition Code - A unique condition code is defined by a 
two-character product identifier (see section 4.1.1.1) 
plus a five-digit error code indicating the specific error 
{eeges IDnnnnn).- Ati COC error numbers must 
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be in the range 1 to $999. Error numbers In the range 
10000 to 195999 are reserved to identify errors from user 
dGeyveloped products» 


In cases where the condition code Is communicated 
In a form other then a status record (e.ge»s FORTRAN 
IOSTATs AAM's ES fieta) the field "condition™ from 
the status record must be used. 


Text - A string used to substitute text into the error 
message template associated with the condition. The first 
character of the text signifies the character used ses the 
text delimiter. Ali text ltems ere terminated by the 
delimiter or the end of text. 


3e4ele2 Embedged Products 


The embedded preduct should return sabnormai conditions to the 
host vla the stendard status variables and with condition code 
and product identifier of the embedded product. Conditions 
anticipated by the host should be transiated by the host into 
the appropriate condition with the host product identifier and 
condition code where user action is required. Conditions net 
anticipated by the host can be passed on to the user. 

Conditions Issued by the embedded product should be clear enough 
for the user to determine required corrective actlon» 

inciuding the need for PSR submittal where appropriete. 


34.1.3 Message generation 


The NOS/VE Messege Generator Is used to format and output 
all error messages output to logs or to an interactive 
users terminal (note this does not include djagnostics 
generated during compilation). It produces a standardized 
message using the NOS/VE status record and message 
temptates from « message dictionary. 


304.2 MESSAGE TEXT 


The message templates ere determined by each product and 
included In a message dictionary. The NOS/VE ERS stould 
be referenced te determine the formats of message 
templates. 
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3.4.2.1 Message_fornats 
The message generator formats and cutputs messages 
eccording to conventions based on the message's 
destination: terminals togs files or returned to the 
caller. 
Terminal: 
Format: text wee.e«. ofr iIDnnnnnn text sacsee: 
Example: Permanent file (pfu) not found. 
Logs OUTPLT» or other File: 
Formats TOnnnnnn Text swescs 
Example: C 80326 Incorrect delimiters comma 
assumed. 
Returned to caller: 
Format: ICnnnnann SID ame text sess 
ExamPje: AM1234 SOP 012 File (ifn) slready 
opened. 
Where? 


text cre Text of message 


ID = Product identifier 

nnnnann = The error condition code. 
{unlque error number for a given 
product) 

SID = Product subidentifier 

mmm = Subconcition code, 


The combination IDnnnnnn will be known externaily as the 
"C180 error number". It is a unique systemwide code by 
which any error message can be identified to the user. It 
Is always printed before the message text on all batch 
iistingse It can opticnaliy be included with messages 
output to an Interactive terminal and is available to the 
terminal user requesting additional error enalysis 
assistance via the NOS/VE HELP facility. 


34.2.2 Ecroc Sumperies_io_logas 


When error summeries are listed on a files log messages 
shouid be Issued to both the system and user iog according 
to the following rules end formats: 
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System and User Log 
n fatal errors [in x} 


User Log Oniy 


n warning or trivial errors Cin x1] 
n number of errors 
x Is the name of thea modules programs subroutine 


that contains the errors. 


Error summaries should only be used when it is 
Inconvenient to provide a description of an actual error. 


Catastrophic errors are not inclucéd because they should 
always resuit in a log message indicating the catastrophic 
error. The efrer counts should be issued to the log even 
If the EL (error tievel) parameter exciudes them from the 
jisting. 


324.2.3 Message_vorgina 


Error messages represent a very importants though often 
MNegiecteds, interface between software and user. Proper 
attention to preducing polites corrects and ciear error 
messages can do a iot toward improving the overall 
usabliity of the system. The following conventions should 
be usec in defirlng error message text: 


* Messages should be polite and courteous. Words such 
as “Iilegail™ Should be ayoldec In favor of words like 
"Incorrect™ or “unknown”. Error messages should» 
where apprepriates suygest whet the user ought to do 
to correct the error. For examples use: 

The fine number parameter must be an integer. 
not: 
Titegal line number. 


° Messages must be formatted for 80 character displays. 
Telegraph styte Is much better than long-winded 
prose. However, the message must be descriptive of 
the error. Messages Jike “Bad Argument™ don't say 
enough. 

° Consistent terminology Is extremely important. For 
system-wide terms consult Section 6.0 of the SIS. For 
terminodogy specific to a products again consistency 
is the important factor. 
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e Identification must be provided with varlabtie 
infermation. For example: 
uses 
Fite (ifn) not found. 
Variable (yar) must be scalar. 


not: 


(ifn) net found. 
Veriabie (var) must be scalar. 


° Use ending punctuation. It indicates to the user that 
the message is not continued on the next line and adds 
to the readability cf the message. 


* Messases stculd be criented tOward an inexperienced or 
casuai user such thet the message can be understood 
and appropriately responded to without reference to a 
manual, 


* Abbreviations should te avoided. whenever possible 
fimit the characters used to alphanumerics plus 
english punctuation. Avoid use of characters that 
appear differentiy on different devices. CDC's 
64-cheracter ASCII subset and lowercase aiphanumerics 
can be usec. 


s Words beginning with “multi"™ end "non" are not 
hyphenated. Don*t use ™"{s)" to indicate an optional 
piural usage; elther singular or plural is acceptabie. 


° Error messages shouid use upPer and lower case as they 
are normaiiy usec In the English language. Upper case 
should be used to distinguish “computer” words from 
normal English words. For example: 


File FRED not found. Specify keyword NEW. 
305 YSAGE STATISTICS 


All products are required to collect and log statistical. 
information. 


This section describes what these statistics afe used for,» 
the NOS/VE Statistics Facilitys which statistics will be 
coliected by preducts and which will be collected by the 
0/S and when statistics should be logged. 


Because the Statistics Facliity is under contro] of NCS/VE 
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product designers are requested to convey statistics 
requirements anc plans to the NOS/VE design team. 


3.5.21 PURPOSE OF STATISTICS 


Statistics logged by products may be used for billing» 
measuring rellabliity, measuring performances debuggings. 
product plianning or some other purpose. The ultimate use 
of the data cannot be determined when the product is being 
designed. For examples a statistic such as "number of 
Soufce statements compiled”, which is normally considered 
a performance statistics could just as easily be used as 
the basis for charging or bliling a user. It*s not 
inconceivable that a student could be billed based upon 
{number of source statements) — (number of comment iines) 
+n * (number of efrors) if this data were avaliabie for 
each compile. 


There are three physicaily different logs for recording 
statistics. They are the accountings Jobs and system 
statistics logs. See section 3.2. A particular statistic 
may apply to one or ali three of these Icgs. To prevent 
products from having to Issue the same statistic several 
timess to prevent product designers from having to decide 
which statistics will be used for which purposey and to 
provide installations and users meximum control over 
statistics gatherings NOS/VE provides a centralized 
Statistics Facility. 


(325-2 STATISTICS FACILITY 


NOTE: This is pretiminary information. The NOS/VE 
ERS should be raferenced for a more complete 
and up to date specification. The ERS ts the 
contrelling document for this product to C/5S 
inter face. 


The NOS/VE Statistics Facility is used by Products and the 
O/S to accumulsete statistics and write records into binary 
logs. 

The Statistics Facility 


- associates a statistic code from a status record with 
a particular table entry 


- adds job and task identification to the variable data 
‘if eppropriate. Task identification specifies which 
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of the possibie severai asynchronous Instances of 
execution within « job the current statistic belongs 
toe 


- routeS the stetistic to the appropriate iog or logs 
and/or adds it to a specific counter as cetermined by 
the tabie entry. Counters can be dumped to binary 
logs at specific times or events. 


Data passed to the Statistics Facility include: 


- statistical code - ordinal of this particular 
statistic. 


- optional byte string — for preducts this string 
contains product IDs module Identifiers if 
appropriates and any other product or statistic unique 
descriptive data. Product ID Is the two character 
identifier defined in section 4.1.1. 


- optional count fields - 0 to n numbers» the numeric 
part of the statistic. 


Data returned iInctude: 

- Status - boolean indicating whether or not the 
previous Stetistic Facility request was processed 
correctly. 

The method for eSsigning statistics ordinais wili be 

specified in the ERS. <A separate range of numbers will 

probably be reserved for userse 
32523 PRODUCT STATISTICS COLLECTED BY NOS/VE 

In generals the O/S is responsibie for collecting job step 

statistics that can be determined external to the product» 

that is statistics that the O/S Is capabte of determining. 

For each product Identified In SIS section 4.1 that is 

directly invoked by the usef,s @eges via command or as a 

program initiated task, NOS/VE will record resources used 

per Invocation. Resources accounted for include: 

_ totai CP-time 

- maximum virtual memory used 


- maximum resl memory used 
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CYBER 160 System Interface Standard 


< average working set size 

ad CP-time per memory size used 

= number of I/0 reauests 

sg amount of deta re@d/written to files 


Additionai data to be coilected for each invocation of a 
preduct include: 


= origin of job step - batch conmands terminal commands 
procecure files executing job. 


- type of termination - normals product errors time 
limits Invalid memory requests operator drops, etc. A 
recovered condition does not cause product termination. 


- average interactive response time for interactive 
products - the average elapsed time between input data 
availabie and output data Issued to terminal. 


- the fact thet the product was jnvoked (added to count 
of the number cf separate inyccations). 


-_ number of modules toaded (input units for the loader) 


= source langueges of modules icaded (added to ijanguage 
usage count). 


- disk accesses per CP second. 

These same statistics» resource usage and @dditional data» 
may be collectec for any user Initiated job step whether 
It is a user supplied program or a CDC supplied product. 
Statistics for products will be Identified by product ID» 
correction ievel informsetion» and tesk number acquired 
during ioading. 


Task number Identifies which invocation of product x 
Issued the statistic. Several asynchronous tasks may be 
executing the same product. Statistics for user written 
tasks may be identified by primary module names task 
numbers and other data gleaned from the file ID. 


Number of invocations will be coilected for ail products 
both user calied and product called service products such 
as Access Methods» and all user tasks. It could be 
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collected for all modules on system libraries. For 
products» it represents the number of times the product 
was Invoked over a given time span; for user programs it 
represents the number of times a program module written in 
language x was used over a given time span. The time span 
is Installation definable. 


3e50e% STATISTICS COLLECTED BY PRODUCTS 


In generals, products are responsible for collecting internal 
statistics that oniy they can know. These statistics provide 
ameans of charecterizing the work performed by a product} 
they are used for evaluating product performance. Statistics 
to be emitted ere specified in the product*s DR. There are 
two classes of product generated statistics - input units 

and Internal usage statistics. 


3504-1 Input_Unlt_statistics 
This class of statistics is concefned with the number and 
nature of user controlled data processed by the product. 
Aii products are reauired to iog number of Input units 
processed per invecation. 


Input units for verlous prodUct types are: 


Product Type Input Unit 
Language translators, such as Source 
FIN» CGBDOL, CYBIL» lines 
Utilities such as SORTZMERGEs FMY Data records 
Services such as AAM Functional 
reguests 


Other meaningful input unit related statistics must be emitted 
by products», Where applicable. AO/R specified measurement of 
performance requires generation of such statistics for certain 
products. Examples of these other input statistics are: 
Language Transiators 

- number cof modules processed 

- number of source statements 


- number of tines consisting sOlely of bianks 
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- number of fines consisting solely of comments 
- number of scurce statement errors for each error ievel 
Utilities 


- number cof recorcs of each recognizable fecord type supported 
by the product 


~ number of records in error 


Services 


- number 
- number 


Many other 
possiblie. 

edditions! 
exampie Is 


of functions of each defined type 
of iliegelisiii-formed requests 


potentially useful input reiated statistics are 
Products developers are encouraged to coliect 
input statistics they feel are worthwhile. An 
source statement frequency» i.@e. number of 


each type of source statemant encountered. 
325e4e2 Internal_Statistics 


This class of statistics Is concerned with internal measures of 
the product as opposed to measures of the Input date. 


An example of such a statistic is: 


product options in effect for this execution e.g.» 
what control statement parameters were selected 


Products are required to log major options selected (such as 
optimization levei usea by a complier). Each product Is required 
to specify which options are major. 
Many edditionali statistics (such es Internal errors encountered) 
May be appiicabie to specific products. Developers are encouraged 
to collect other statistics they feel are worthwhile. 

32525 WHEN TO LOG STATISTICS 
The two issues of concern are: 


- when should detailed optionals statistics be 
accumuijated and flogged? 


~ when should subordinate service products such as AA 


ee ae on wi 


aie 


dead 


oe 6 Ch BH GH OU we aH 


Se BS SS au GH we be oe 


3-45 
CYBER 180 System Interface Standard 
86/02/04 
3.0 OUTPUT | 
325.25 WHEN TO LOG STATISTICS 


log statistics? 


All statistics wiil be controlled by installation or user 
contrelied switches. The statistics Facility will provide 
the mechanism for setting and clearing these switches. 
Each procedure that Issues diagnostics must check the 
appropriate switch before calling the statistics 

Facility. The switches will probably exist as an array of 
blts that can be referenced but not changed by user 

tasks. The NOS/VE ERS will specify the exact form. 
Subordinate products and routines may either issue 
continuous statistics at product determined intervals or 
events or they may accumulate and report them under 
control of the host product. 


For products such as AM and AA whose statistics could be 
meaningful regardiess cf the hosts the first approach is 
acceptable. For examples statistics could be gathered 
from file open to file ciose for each file. Anyone 
Interested in AA statistics for a job step would have to 
sum up the Individual statistics on the log file. 


For subordinate products and routines SUch as the common 
complier modules whose statistics are not meaningful out 
of contexts 2a mechanism should be provided to enable the 
host to force out statistics on demand. That iss the host 
must be able te tnform the subordinate that its work is 
complete. If the subordinate actusaliy Issues the 
statistics, the host must provide its product ID to the 
subordinates so that ID can be Included In the 

statistics. If the host actually Issues the statistics 
the subordinate must return ali date and identifying 
inforMation. The first method is preferred since the host 
does not need te know which or how many statistics the 
subordinate is collecting. 


Note that all methods of statistic reporting require 
products to receover from catastrophic external and 
Internal errors. Products must regain control so that 
they can output the accumulated statistics. Furthermore, 
since O/S togs the reason for terminations products that 
recover from abnormal external conditions must be abie to 
fet the abort heppen after they issue their statistics so 
that the correct reason for the termination Is recorded. 
Products that detect internal errors must be able to 
indicate that such an error happened when they aborts, so 
that “internal error" is recorded as the reason for the 
abort. A product may choose to terminate via an abort 
when no product error has occurred. 
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4.0 SYSTEBWLDE_ CONVENTIONS 


This section describes the operating system and product 
set convention srhich must be followed ty ail standard 
software. 


The term “global” as used in this section refers to 
constant and type definitions that ere global to several 
products. It does not mean “gilobal"™ within a particular 
product. 


4o1 NAMES2 DATES_AND_IIMES 


Standerd syste™ naming conventions ars needed for the 
Ffoiiowing reasons: 


1. Permit recegnition of the origin and maybe the purpose 
of the Named entity just by Its name. 


2e Prevent duplication of names between different 
products. 


3. Designate categories of names that are reserved for 
CDC usage so thet they will not be dcuplicated by 
application programmers. 


These names may be declared as entry point names» file 
names» SCU deck names» or as names for common system 
entities such as instailation options. The common system 
entity names must be declared in e form that provides a 
Simpie source of avallabiliity for use by any system 
impiementation languages (CYBIL or assembly). 


421.1 NAMING CONVENTIONS 


Tne system defined giobal names will be generated 
according to the following convention: 


PPCSXXX 
wheres 
PP -=— [Is a 2 cheracter alphenumertc product 
Identifler or other gicbal identifler for the 
owner cf this symbol. 


Cc --— jdentifles the class of the name. 
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$ -- js the speciel character 4 

XXX == 2 or more alphanumeric characters which 
establish uniqueness within the fleveis of 
identification described above. The maximum 
length of this fieid Is determined by the other 
users of these names. Example: The loader 
determines the maximum length of an entry 
points the record manager the maximum length of 
a file name. 


4.1.1.1 Product. Identiflers 


AA Advanced Access method 

AD Ada 

AL Assembly Language 

AM Access Method 

AP APL 

AV Accounting Validation 

BA Basic Aceess methods 

BC BASIC -« 

cc Common ComPlier modules {CCM) 

CB COBOL 

CF CYBIL Fermatter 

CG Common code Generator (CCG) 

CL Command Language 

CM Configuraticn Management 

cs Character virtual terminal Screen management 
CU Concurrent maintenance Utilities 
CV CYBER Vectorizing Code Generator 
CY CYBIL 

DA DCN dump Analyzer 

DB _Anteractive Debug 

ie Distributed Communications 

DD Data Dictionary 

DF: Distributed Files 

DM Levice Management 

DP Display 

DS Deadstart/recover y 

DU NOS Dump Analyser Utility 

ES Edit Screen 

FA File micration Aids 

FC FORTRAN Comeliler 

FD Format Cispliay 

FL FORTRAN run time Library 

FM File Menagement (in BAM) 

FM File Management utility 

(Double use of FM to be resolved by DAP» If there is a probiem) 
FS File System 


FT FORTRAN. Global to FC and FL 


ee we 
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COC FORTRAN (Vectorizing) 
Graphics virtual terminal Screen management 
Hardware Performence analyzer (HPA) 
Help Utilities 

Interstete Communication 
Interactive Facility 
Interactive Interface 
Information Management 
Input/Cutput 

Job File manager 

Job Mansgement 

Job Swepper 

Keypoint Reporting Utility 
Logs 

LISP 

Loader/Library generator 
Logical Name 

Loader 

Link User 

Maintenance Application Language for Equipment 
Testing (MALET) 

Marketing Configurator 

Math Librery 

Memory Management 

Matrix Aigorithm processor 
Malntenence Services 

Monitor 

MAIL/VE Electronic mail system 
Network Access method — 
Network Configurator 

Network File Trensfer 

Network Performance 

Object Code utilities 

Cperator Facility 

Ceperating System 

Pascal 

Programming Environment 
Permanent File management 


(to be phased outs per SIS Dap $4730) 


PM 
Pp 
PR 
PS 
PT 
PU 
Pi 
OF 
QU 
RF 


Program Management 

Peripheral Processor 

PROLOG 

Product Set 

Performence Tools 

PF Utilities 

PLyI 

Queued Files 

Query Update 

Remote Host Fecility Access Methods 


ee ee 
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RH Remote Host facility 
RM Rescurce Management 
SC Source Code utility 
SD Screen Cesian Facility 
SE Set management 
SF Statistics Facility 
SM Sort Merge 
SR Conversion services 
ST Seftweare Tools 
(Current use of ST for Sets wiil be phased out in favor of SE) 
SV Shared Varlebles processor 
SY System 
TD Test Data base 
T™ Task Manager 
TU Terminal Utility 
TW Transiater Writing System 
US User (eege» for “user™ statistics) 
UT Tests 
vec C Compiler 
vx VX/VE =- UNIX Emulator 
zs zeus 


4.1.1.2 Qtbec_Glotal_Identifiers 
RA Release Administrator 
This product Identifier is used to identify 
Installietion parameters and procedures associated 
with a NGS/VE product. 


4.1.1.3 Classes_of_Names 


The following tist cof identifiers naming classes is used 
for code and deck naming purposes: 


A -=- architectural and design documentation 


B -- design documentation (internal to CDC). 
Also the three following special blocks: 
CYBSDEFAULT_HEAFP 


DEBSNE_-LINE ENC GUNTERED 
DBBSNEW_PROC_LU ENCOUNTERED 
C -- constant 
DB -- decleration {decks containing types and/or 
constants) 
-- exception condition name 
~~ file 
documentation {headerss inline text) 
-- Inline coce or installation/integr ation 
~- keypoint or keyword 


Kee Ten 
f 
t 
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M -~- module 

P -=- procedure 

S$ -- section (static data section and/or common 
T 

V 

X 


block) 
-- varieble Ape fide 
~~ XDbCt4d (decks containing procedures or Po a i, 


_wartiables) 


4.1.1.4 Soecial Characters 


The use of the $ sign in a name identifles the name as one 
beionging to COC. CDC users will avold any dupticaticn 
with CDC names by not using the $ in any of their nemese. www... 
Some programming languages such as FORTRAN do not ailow 
imbedded doitlar sign cheracters in their names. COC 
supplieo procedures caliable from these ianguages will not 
conform to the £ sign rule. 


401.1.5 User_Giob2l_Names 
User giobal names follow the rudjes defined In 
sections 421.21-4.21.1.45 except the form of a 
user giobal name is: 
PPC#HEXXX 
4.1.1.6 Deck Nagios. Guldellpes 
Relationship of Code and Deck names 
The deck name must be the same as the code nare whenever 
possible. In instances where it is absolutely necessary 
to group typess constants, etc. in the same decks then it 
Is allowable to use a conglomerate deck name which Is 
different than the component code names. 
"Design Documentation” Deck Names (A and 8B) 


Ciass A decks are for architectural and design documentation 
releasable with the code. 


Class B decks are fOr requirement/design documentation not 
reieasabie with the code (e@.ge» DR-type specificationss such as 
performance) but relevent to code maintenance. 


A “design documentation" deck haS the EXPAND attribute vatue of 
TRUE or FALSE»s cepending upon the needs of the product. The content 
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cof this deck end all decks *COPyed by this deck are input to the 
processor naméd in the PROCESSOR field of the SCU deck. The PROCESSOR 
is in the form of a string which represents the command by which the 
processor Is invoked. Documentation decks may not be processed by a. 
compiler but rather by a text formatter processor. For Instances 
documentation decks might be processed on the €i7903; then the 
PROCESSOR might be TXTCODE. In the futures documentation decks may be 
Processed on the C180 by a text processor. 


Documentation decks not to be released to customers must be 
Identified (by group) by the development project to Integrations 
which will remove such decks during preparation of SMC release 
materials. 


*Compiilabie™ Deck Nemes {M and F) 


A “compilable™ deck has an EXPAND attribute value of 

TRUE» The content of this deck and ali decks *COPYed by 
this deck are input to the Processor named in the 
PROCESSOR Field of the SCU deck. The PROCESSOR fieid is 
in the form of a@ string which represents the command by 
which the processor is invoked. Parameters which are to 
be passed tc the precessor,s and which are meant to be 
Invariant {such as optimization levels or debug level), 
may be included in this string. The order in which 
invariant parameters are specified Is precisely the order 
in which they are defined for the commands even though the 
parameters are specified as equivelenced parameters.» Fiie 
references are disallowed In the processor string. 


M class decks contain a processor defined “compilation 
unit™. Examples of such compllation units ares MODULE to 
MODEND for CYBIts IDENT to END for ASSEMBLE» PROGRAM to 
END for FORTRAN, etc. Moduie decks represent the units 
which are maintained In a Binary Mocule Replacement 
environment. <A perent/child relationship exists between M 
and P (or V) decks which contain XREFs. To denote this 
association, the name of the parent M deck Is assigned as 
e@ GROUP attribute of the child P or V deck. Thus» any 
modifications mede to the chiid deck resuits in the 
ability to generate the parent deck by interrogating the — 
GROUP attributes cf the child deck. Likewise, ati decks 
which *COPY the child deck can be gén@rated through use of 
the INCLUDE _COPYING_DECKS Criteria File directive. The 
naMe assocjatec with aM class deck is the same as thet 
specified on the MODULE» IDENTs PROGRAM, etc. statements. 
If aM deck contains code which is later Bound into a 
Module of a different name via the BIND_-MODULE subcommand 
of CREOLs, then the name of this Bound Modute Is assigned 
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as a GROUP attribute of the M deck. The name Of a 
corresponding F deck which contains specific CREGL 
directives associated with the binding of this module Is 
specified as a GROUP attribute of this M deck. 


F class decks cOntain Source data which Is retained as a 
files or contains processor directives for the processor 
named by the processor fieid. These decks contains or 
*COPY decks containings information necessary for 
establishing program descriptionss omitting entry points 
from Bound Moduless or establishing SCL procedure 
‘libraries. A typical F deck might contain COLLECT_TEXT 
and ADD _MCDULE commends, and *COPY*s to procedure decks (P 
decks) which contsin the source of procedures to be added 
to a procedure library. Another use of F decks is es a 
container for directives to the Real Memory Bulider or 
Virtual Memory Linker in which segment attributes are 
defined. If a SCL procedure is to be executed from a file 
rather than a procedure ijbrary»s, then the processor type 
of the F deck is SCL rather than CREGL. The name 
associated with F decks is the name of this file as It is 
accessed when the processor is Invoked» or the name of the 
resultant fille which {Its to be created. 


"Non-compilabie" Deck NeMes (C» Es» Is Ks Ps Sa Ts VY) 


A *"non-compilabie"™ deck is one with the SCU deck EXPAND 
attribute value of FALSE. This type of a deck is *COPYed 
by “csompilabie"™ decks and assumes any attributes 
associated with the *COPYing deck. 


K class decks contain KEYPOINT» KEYWORD» or statistic 
codes. These codes are defined in terms of a constant 
plus relative offsets and define « set of related deta. 

K decks are given a conglomerate name which indicates the 
type of data being described (KEYPOINT, statistics or 
KEYWORD). 


C class decks contain Constants. Constants are used to 
Impose an upper limit on ranges» end provide a starting 
point from which reiative offsets are computed. A 
constant is giobal in nature by virtue of Its appearance 
In aC decke Those constants which define product 
restrictions due to their design (eg. OSCSMAX_NAME_SIZE), 
and those constents which represent Instaliation options 
ere the two categories of constants with packaging 
affects» The fcrmer category of constants are named so as 
to describe the scope of effect upon other products or 
subproductse Froduct specific constants should be named 
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using product specific two-character jdentiflers. The 
flatter category of constants are nemed with the RA product 
identifier to indicate that the "Release Administrator" 
assumes ownership for the vaiue assigned to the constant. 
Since source cede will be unavailabie at many sites» the 
use of constant values must be avoided. Global constants 
should exist as one constant per ceck. The name of the 
deck should be the same as that of the constant being 
defined. Ownership of a constant is assumed by the decks 
which *COPY a constant deck. Automated generation of ail 
decks affected by a change to a constant deck is 
accomplished through the INCLUDE _COPYING_DECKS Criteria 
Flie Directive. 


JT and E class cecks contain Types and Exception conditions 
respectively. Since Exception conditions are typically 
described in terms of a constant pius a relative offset, 
it is acceptabie for a constant declaration to appear 
within the E deck. £— decks are given a conglomerate name 
for the condition range. Types may be either fixed or 
adaptabie. In such cases where a type is defined in terms 
of constant (such as an equivatenced ordinal type) then 
the constsnt velue may be contained in the T decks. T 
decks are named the same as the primary type defined in 
the deck. If the type is a records then the name of the 
dack is the name of the record defined In the deck. 


P class decks contain code procedures. The content of 
such decks Is the source of non-XDCL'd proceduress SCL 
procedure definitionss or XREF decierations for XDCLt#d 
procedures. A SCL procedure definition will contain a 
PROC to PROCEND sequence if the P deck is used to form a 
procedure library, otherwise the procedure will be defined 
in a F deck, Code sequences which are not bracketed by 
PROC to PROCENDs or a corresponding sequence such as 
SUBROUTINE and ENDs should be contained in I lintine code) 
class decks. Each external procedure should have an 
accompanying H deck that decuments the procedure. 


V class decks Centain variable declarations» or the XREF 
to XDOCL"d vartebies. <A chilid/parent reiationship exists 
between a V deck contsining an XREF and the corresponding 
M or € deck in which the variable Is XDCL*d. The name of 
the V deck is the same as name of the variable which Is 
defined in the deck. The name of the parent M or F deck 
is assigned as 2 GROUP attribute of the V deck. 


H class decks contain documentations such as headers or text 
that may be called into a generated document such as an ERS. 
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(A and B class decks may be used for high-fevel architectural 
and design documentation. H decks may be used for detalied design 
documentations particularily to support external procedures.) 


I ctass decks contetn inline code or integration/instaliation 
parameters. If the case of codes the justification for such 
decks involves performances where repeated code cannot be 
formed into a PROCEDURE due to the expense incurred in the 
procedure cali. Gtherwises FUNCTIONS or INTRINSICS may be 
contained in I cecks. Inline text is text used for code 
Pocumentation purpOses which may also be calied inte e 
generated document such as an ERS. 


S$ class decks contain blocks of related data such as 
static data of Common Biocks. An aggregate name is 
associated with this ccliection of data unless the text 
data describes a specific entity. In such cases» the text 
data assumes the same descriptive string as that 
assoclated with the entity it is describing (leg. 

OSS SMAINFRAME_PAGEABLE_ HEAP). 


"Non-complilabile™ Deck Names (OD» X) 


Decks belonging to this category reprasent packaging 
anomaliess and should be avoided whenever possible. 


D class decks contain conglomerates of Types and/or 
Constants. Since it is difficuit te ascribe meaningful 
Identity to such combinations, the use of the D class 
should be avoided when possible. It Is advantageous to 
define parameters for procedures in a D class deck. This 
anomaly exists cue to the nature of the constructs 
necessary to cefine g¢rocedure parameters... 


X class decks centeain the XDCL definition of procedures or 
variabies. The recommended location for the source of 
XDCL*d procedures or variables is within a compijable deck 
(M or F class)» Combining XDCL'd procedures into a single 
module is a function of the CREATELOBJECT LIBRARY utility 
command BIND MODULE. If the XDCL'd procedure Is GATED to 
other products end/or userss then the XDCL'd name Is 
preserved as a result cf Bindings otherwise the name is 
discarded provided there is a corresponding XREF at 
blading time. Therefores it is a product's responsibility 
to CHANGE _MODULE_ATTRIBUTES of the Bound Module to GMIT 
names within Bound (or Unbound) modules which are not to 
be externalized by the product. it is recognized that 
baling abie to combine several XDCL'da procedures and/or 
variables into @ single compilation unit can provide 
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additional debug capabilities provided by a compiler. It 
ls for debug purposes that X class decks exist. 


4elele7 SCU_GROUP_ NAMING GUIDELINES 


Critical to the structure of the products source tibrariess and 

to the efficiency of the source maintenance proceduress is the 
association of SCU "group names" with each deck on the Iilbrary. 
These groups mey be used to menipulate “biocks™ or “groups” of 
decks» such as ali decks In a job template or system core library,» 
fairly easily. 


The different types of groups are identified by the conventions 
used to name them. Except for the “processor™ and "generic™ groups 
{described below), the format of ali group names is: 


XxxyS$aagada 


where xx’? Is the product identifler, “aasaaa" is a descriptive name 
for the particuler groups and "y" is One of the following: 


S Specifies a "Source™ groups i.e. a subdivision of the 
source llbrary into component ilbraries. Severai 
examples of groups cf this type are: 


esssprogram_interface l(osf$program_interface) 
festfront lend 
cbsicotol source 


F Specifies a “destination File" group (jee. a file onto 
which a deck is to be placed after processing). Several 
exampies of groups of this type are: 


aaf$44D_library 
osf$monitor 
osftobject cede utilities 


G Specifies a "Group™, i.e. a cOllection of decks that 
have been decided would be useful to be able to refer to 
en massee Several examples of groups of this type are: 


chgsprocedure_common_decks 
cbgSrun_time procedures 
fegtbridge modules 


NOTE: All decks on the source library which belong In the IJibdrary 
psfsexternal_interfece_source should be associated with the group 
name “psfSexternsal_inter face source". Keypoint decks and error 
codes should aiso belong to this group. 
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Most other group names will foliow the conventions described in 
the previous text for the product source libraries. Howevers there 
are two classes of groups for which this is inappropriate: 
“processor™ groups ana "generic™ groups. 


A "processor" group will be given the same name as the 
corresponding pfocessors, @e9 the group name for decks to be 
compiled by CYBIL will te "CYBIL". Other processor group names are: 


assemble 
fortran 
cobol 
pp_compass 
cp _compass 
cybil_ce 


Note that some of these must obviously be processed on the NOS 
side of the machine. 


A "generic" group Is used in those cases where knowing the 
processor for a deck Is insufficient for some purpose. The generic 
qroups thet have been identified and are requireds if applicable, 
2re: . 


common 
program _descripctiors 
message_templates 
sci_procedures 

ccl _procedures 
scu_selection criteria 
bulld oprocs 
deleted_decks 


Ail decks which are called by other decks will belong to the 
Group "common". when a deck needs to be deleted» it should betong 
to a group “deleted decks". At this point in times the deck Is not 
really deleteds so the buiid procedure must be specificaily 
exciuding this deck until someone In Itintegration can physicaily 
delete the deck. This will onty be done between releases to Insure 
our ability to back up to a previous level. 


Some of these generic groups overlap to some extent w«aith the 
procassor groups. 


A deck may have up to 255 group names assoclated with ite At 

this point In times a group cannot be associeted to anecther group. 
A DAP has been written to allow this capability. For the time 
beings issue the change _ceck SCU command to establish ali deck to 
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group associations. 
4.1.2 RESERVED FILE NAMES 
The following files will have special uses: 


INPUT Is that portion of the primery input flie that 
follows the System command statements. 


OUTPUT is the primary ocutput file and contains a Copy of 
the job dayfiile et the end when printed. 


For interactive jobs» the terminal is assumed to be beth 
INPUT and OUTPUT. 


421.3 DATE AND TIME 


White NOS/VE provides date and time data in several 
formatss products are restricted to using one format 
unless language standerds dictate otherwise. The forwat 
to be used Is the Installation defined default format. 


For fixed position tisting and file formats, date and time 
fleids must be large enough to accommodate the longest 
forms returned ty the G/5S. 


42 INTERACTIVE PROCESSING 


Tails section tdentifies capabilities products must provide 
to support users interfacing the system from interactive 
terminals. 


Products support different ievels of interactive usage. 
Therefore a product does not necessarily support ail of 
the capabllities described below. For examples products 
that typically perform tatch functions (e.g. compile 
FORTRAN source) do not provide the same level of 
Interactive capabliity as one that typically performs an 
interactive function (e.9. query a file). 

Many of the capabilities are provided by the operating 
System and therefore are avaliable to ali terminai users 
independent of the prograu/application being used. 


Specific interective capabllities to be provided by C180 
products are described below. A key is used to indicate 
which products must Inciude design and implementation of 
the capabilities. The keys sare: 


A- It is the responsibility of ali products to support 
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the capabilities marked with the A key. 


This kéy notes the terminal capabliities supported in 
the Implementation of the operating system. These are 
avaliabie with ali interactive usage and are provided 
by; 


Job Management 

Message Generator 

File Routing 

Basic Access Method 

Transaction Executive 

Network /Communications Access Method 


os 6» © 6 6 @& 


This key notes the terminal capabilities supported by 
"Interactive products™. These programs normally carry 
on ea dlalogue with a terminal user to obtain feedback 
and dynamicatiy direct processing. They Include: 


Job Manegement 
Message Generator 
File Routing 

HELP Utility 
Transaction Executive 
BASIC 

APL 

OS utilities 
Cuery/Upcate 

Report writer 

FMU 

Interactive Debuggers 
SORT/MERGE 

SCu 

Editors 

Conversion Utilities 


*® @¢ ¢ &@& © © 6 © © © @ 6 @ 6 hU®hUM 


4e2e1 INTERACTIVE OUTPUT 


4.2.1.1 General 


a) 


b) 


The page width and ftength at an output device veries 
not only by device type» but also by the size of paper 
being used In the device. The user must be able to 
Indicate the operational page width and page length of 
the output device. Defaults thet correspond to the 
terminal characteristics are supported. 

-O- 


Lines of data that exceed the output device page width 
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must be delivered without loss of data. Data that 
would be output teyond the right side of the page must 
be folded onto a second or successive line (reference 
aecriae Ze rol sed) 


c) The user must be able to have every output line 
formatted so as net to exceed the output device page 
width provided the output device page width Is not 
less than 80 characters. As a minimums, the user must 
be able to specify that output be formatted for page 
widths of 86 cr 132 print posIttions (reference 
section 3.34124). 
=~ G— 


dad) <Any output that may go to an ASCII sequentiai file may 
Instead go to a terminal. 
-O— 


e) <Any output may contain a carriage control character 
{reference section 3.3.1.3). 
-O— 


f) The carrisge controi character will direct printing of 
an output file anc will not appear in the print output. 
-o- 


4e2e1.2 Messages 


a) Messages must be cOurteous. Words such as “illegal” 
Showid be avoided in favor of words like “Incorrect™ 
or “unknown"™. Error messages must» where appropriates 
suggest what the user ought te do to correct the error. 
om Jim 


b) Messages must be formatted for narrow jiistings. 
-A- 

c) Messages must be meeningful such that an inexperienced 
or casual user is able to understand the message and 
respond appropriately without reference to a manuel. 
-A- 


qd) Any message tonger than 20 cheracters must have an 
alternate brief counterpart. 
-A- 


e) A user mUst be able to select either a brief or tong 
form of a message- wWhen using the brief form of 
messages the user should be able to request that the 
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last message be repeated in its long form. 
-O<— 


f) Messages sciliciting input (prompts) should aiways be 
used to indicate that the user Is expected to supply 
Input. 


qa) Prompts shculd appear on the same Jine as the input 
whenever physically possible. 


4222123 Listings 


a) Pages of output that are ionger tian the output device 
page length must be delivered without loss of data. 
Data that exceeds the page length must be continued 
onto @ second cr successive page. 

-0- 


b) Pages of output must not be delivered to a 
nen-hardcopy output device so Fast as to overwrite any 
previous output before the user can read it if a walt 
option has been selected by the terminal user. 

-O=< 


c) The uSer should be able to have heading information 
repeated on the second and successive terminal pages 
of a listinge When display space is timited and the 
information band width is lows the user might choose 
to not use space to dispiey repetitive headings and be 
abie to see more data. Where the listing consists of 
meny columns that are hard to differentiates the user 
might choose to have headings repeated on every page. 
This capabliity requires thet: 1) Page Header text be 
identified so it can be discarded, and 2) Title text 
be Identified so It can be replicated. 

-JI=- 


ad) when initiating a function the user must be abie to 
select aiternate amounts of detall to be inciuded in 
the listing. By selecting Jess details the user ought 
to be able to have more items displayed on each page» 
and not just get less Information per page. 
-A- 
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4e222 INTERACTIVE INPUT 
These standards suppiement section 2.3. 


4.22.1 General 


a) User discovered typing errors must be correctable by 
backspacing and retyping. 
-0- 


b) The user must be abie to cancel the ingut line being 
typed at any point before input completion Is 
indicated. 

-O=— 


c) No extraneous bianks will be eppended to the end of 
the user defined input data for padding. Application 
of this rule is oniy required 1f allowed within a 
product's standard. 
-A- 


@) No user typed trailing blanks aill be deleted from the 
input data. The application of this rule is only 
required if allowed within a product*s standards. 

-A=- 


e) Any input that may come from an ASCII sequential file 
may instead be supplied by a terminai connected as 
thet file. 

-A- 


Ff) A single input may consist of more then one fine. A 
prompt may cellow multiple lines of input in response. 
An Input co§lection mode may be implemented in this 
manner. 
-0=- 

g) Operations requiring only a few parameters should not 
require more than a single Input. The user may enter 
all parameters for a directive or all directives for a 
Single system level command es a singie Input in order 
to reduce the number of interactions and the time to 
compiete the directive or command. 
-O- 


h) The user must be able to use the standard 
abbreviations for command names,» directives and 
paremeter identifiers in order to reduce typing. 
-A=- 
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1) After input of a command or directive has been 
completeds incomplete Input should not be treated as 
an errors but shouid cause further prompting for the 
missing parameters. 

-[- 


4.2.2.2 Input _Dlagooses 


a) Errors In Input wild obe ciagnosed immediately 
foilowing the offending input tine. 
=-I[-=- 


b) Diagnosed Input errors must be correctable without 
"exiting™ the dialogue with the program. 
-jJ- 


c) Where possibie allow diagnosed input errors to be 
corrected without re-entering the entire line. 


d) <Any input diagnesed to the terminal must be 
correctabie by terminal input [amediately following 
the alagnostic whether or not the original Input was 
from the terminal (see 4222321). After receiving the 
corrected input from the terminal Input will revert to 
the primary source. 


4.2.3.1 Cannectlyliy 


a) The us@r must be able to have his terminal connected 
as an ASCII sequential Input file and an ASCII 
sequential output fille for any program. 

-A- 


b) The user must be able to suppress the verification 
listing of ineut when the input source and the cutput 
destination are both the terminal. 

-~A- 


c) Products thet allow input directives from a file other 
than INPUT must allow the user to have input 
directives from se source other than the terminal 
listed for verification at the terminal. 
=oA- 


d) Products thet allow Input directives from a file other 
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than INPUT must aliow the user to have input 
directives from a source other than the terminal 
diagnosed to the terminal. 

~A- 


e) The uSer should be abie to logically disconnect the 
terminal from an executing program without causing the 
program to be suspended. The program should continue 
execution and the user should be able to 
simultaneously enter other commands (including 
execution of other programs). 

-O- 


4.2.3.2 Interruets.anc Connection. Breaks 


a) The user must have a method for galning control over a 
program In execution. This is known as an interrupt. 
-(C- 


b) An Interrupted program will not be aborted as a resuit 
of the interrupt. 
-9=— 


c) Fer a program written to axecute In an interactive 
environments an interrupt must cause the program to 
enter a known state. This state will normaliy be one 
that solicits directives or commands from the teérainal. 
-[= 


d) For a progrem written to execute In a batch 
environments an interrupt must cause the program to be 
suspended in such a manner as to de restartable during 
the seme terminal session. Control ts returned to the 
command language interpreter. 

-0- 


e) <A connection break is often caused by a communication 
fine failure. A connection break must not cause the 
terminal session to be aborted» but must cause it to 
be suspended in such a manner as tc be restartabie 
when the terminai user can again get connected. 

-0— 


f) A user must be able to restart eae suspended program. 


-O=— 


go) <A user must be able to terminate a suspended program 
without first resterting it. 
-0O— 
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bh) A program written to execute In an Interactive 
environment must accept a termination directive in the 
state entered as a result of an interrupt. This 
directive must be the same as the corresponding system 
command to terminate a suspended program. 
-I- 


1) Any incomplete terminal input request from a program 
that is suspended should be reissued (with the proper 
prompt) when the program is restartec. 
cas I~ 


J) The terminal user must be able to Interrupt the output 
being delivered to the terminal and cause the 
remainder of the output to not be delivered to the 
terminal until the next prompt. 

-o- 


4.2233 Status 


a) The termine! user must be able to solicit a report to 
determine the process of a programs, without causing a 
change In the state of the program. 
ae 5 


b) Progress reports must Indicate the functional progress 
of the program. For examples 


“compliiing progtam SAM...” 
“compiling subroutine TOM..." 


“preparing giobal cross-reference...” 


c) The terminel user must be able to solicit a report to 
determine the system environment within which a 
program Is running without causing a change In the 
state of the program. An instaliation option to 
disable this must be provided. 

-O- 


d) The system environment report must indicate (possibly 
indirectiy) the response time the terminal Usef can 
expect to experience. This might be by Indicating the 
length of swnap-out queues» the number of interactive 
users» etc. An installation option to disable this 
must be provided. 
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e) The terminel user must be abie to solicit a report of 
the state ef Its pregram without causing a change in 
the program's state. An installation option to 
disable this must be provided. 

-0- 


f) The program state report must indicate the rate at 
which the user's program Is progressing relative to 
real times end the Iimpadiment to progress. For 
example: 


"014223213 ~ 2.54 CP seconds Swapped Out" 
"014524240 - 5.72 CP seconds Running” 
"014227210 - 6.21 CP seconds Finished™ 


Possible stetes should recognize the points of delay 
in the system; these might be Pagings Swap-outs 
waiting for terminal input» etc. 


9) The terminesi user must be able to define terminai 
attributes to be essociated with an interactive 
session {(eec.» backspace characters, echo modes screen 
size). The terminal user must be able to display the 
terminal attributes currentiy in effect for a terminal. 
-O- 


&o20304 Hele 


a) The terminal user should aiways be abie to yet a 
reasonable response to the input HELP. The response 
should identify the user*s aiternatives and possible 
correct Input. As a directives HELP should indicate 
what directives are able to be used at that point. 
The user should be able to proceed after the response 
to a HELP input as if the interaction had never taken 
place. 

-C- 


4.20% PRODUCT SET RUN TIME COMMANDS 
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4e2e4-1 PAUSE and SIOP Literal 


PAUSE n (In FGRTRAN) end STOP literal tin COBOL) are very 
similar. They should be processed in the same way. . 


&. The message PAUSE text will te displayed on the 
operator's termine! or conscile. Text is n or idterali» 
and is a maximum size of 583 characters. For batch 
Jobs» the cperator is the primary system operator. An 
OFPSSEND TO OPERATOR with an CPERATOR I0 of *#SYSTEM 
OPERATOR* is executed to senda the message. For 
interactive jobs» an AMPSPUT NEXT request referencing 
the flle OUTPLT is executed tc send the message. This 
will resuit in a message on the terminal. 


b. In betchs an GFPSRECEIVE FROM OPERATOR with the WAIT 
perameter and the Same id as above is executed to 
suspend the job and walt for the typein from the 
system operator. The operatecr will respond with a 
REPLY ACTION command. In interactive modes an 
AMPSGET NEXT request on the file INPUT 185 executed 
ithis may not be legals another connected file may 
have to be used). In eaelther cases the data is thrown 
away and the job Is continued. 


4e2e4e2 ACCEPT_EROM_CONSOLE 


The ACCEPT FROM CONSGLE {in COBOL) should be processed In 
exactiy the same way as STOP literal (4-2+4.1). Text 
would be the data from a previously executed DISPLAY UPON 
CONSOLE WITH NC ADVANCING or the message "ENTER COBOL 
INPUT VIA REPLY ACTION® if there was no DISPLAY. 
Interaction is with the syStem operstor oniye (If 
meSsages sent via OF PSSEND TG OPERATOR aiso appeared on 
the terminals, it could cause confusion for the terminal 
operator.) 


403 INSTALLATION. PARANEIERS 


NOS/VE will permit modification of eli system parameters 
dynamicaliy during system executicne The term 
“Installation perameter"»s as used in the ciassical CDC 
senses is not valid for NOS/VE. 


System perametérs fall into the following general 
categories: 


P Hardware cheracteristics (@eG9e»s # of CPU's, type of 
CPU) 
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. System and product defaults (e.ge» cefauit tape 
density) 


® Accounting parameters 
r Limits parameters (e€ege» maximum FL) 
* Timings parameters 


System parameter defaults can be set at the following 
times: 


* Complie time (compilation at CDC) 
‘* Bulld time {deadstart tape bulld at user site). 
° Deadstart time (via operator type-in) 


These parameters may be tested dynamlicaliy and action 
taken accordingly. The product set will require no 
parameter specifiaetions and will dynamically test system 
parameters during execution via requests to NOS/VE. 


The following table indicates the permitted range of 
system parameter control for the product set and operating 
System. An X Indicates that the sption is allowed, and a 
bilank entry iIndicetes that the option is not allowed. Any 
exception must have the explicit approveli of ADEC. 


Ao Se ee ae ae ee en a a he ee ee ee we we ee er ee ee ne cae oe nea te ca ew a ep dp cae een ca eae ce en ee an a ae cn ofp 
Time of Set { Set Times $! Use Times H 

and Use +t--<-----+4----.-. fone we $m eee eo ns 

Type of : Comp. } Buitd $ DJS 2! Exec. 3! D/S ! Exec. ! 
Parameter ! Time ! Time ! Time 2 Time !! Time ! Time ! 


Ce ee, ee ee ee ee es ee 


Product Set § : 4 i i! 3 } 
Hardwere ! 1 ! : a8 : X 3 
Defaults ! 4 i ! a! ! ! 
Accounting 3 3 : } 43 3 i 
Limits H 3 a 4 43 § X § 
Tunina : 4 : ! 3! 3 3 

; 3 3 i 3} 3 ! 

oS 3 : { 3 3 3 ! 
Hardware 3 x : X 4 x 3 X a3 x $ X j 
Defaults 3 x 3 X } xX $$ x 8! xX § x : 
Accounting | x § x H xX 3 x 3} x 3 X i 
Limits ! X H X : x 3 X a! x § X ! 
Tuning : x 4 xX | xX 3 x 33 xX 3 x | 
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fo ee er ne ee een few eee eet ee en fe ee ft ow ee nf fo nn foe ene + 
4.3.1 GENERAL GUIDELINES 


As a senerai rufes the number of system parameters should 
be kept to an ebsolute minimum. This will minimize the 
additional testing imposed by these options and will 
reduce the number of “different” versions in the fiela. 


A firm requirement on both the operating system and the 
product set IS thet no recompilation at a user site will 
ever be required to install the software. This is ¢ 
requirement of binary release. 


4.3.2 LIST DF PRODUCT SET PARAMETERS 


The following system parameters may be tested dynamically 
by the preduct set via requests to NOS/VE (Including 
networking): 


type of CPL 

OS name and version 

line width or screen width 
terminal type 

screen length or page length 
print Lines !timit 


4-4 EBROR_ PROCESSING 
The purpose of this section is to describe the conventions 


and responsibliities of processing different error 
conditions. 


es 6 6 #@ © @ 


404.1 STATUS VARIABLE 


Adil command and procedure interfaces to the system that 
are visibie to the end user must have a status variable as 
a parameter. The status variable is used to convey the 
result of the command or procedure ands» In case of error, 
provide Information explaining whet went wrong. 


For commandss the status parameter shouid always be 
optionale When It Is quoted by a user» the assumption Is 
that the variable will be tested subsequently in the 
command stream end some eppropriate action taken. 
Therefores the conditions returned to the user should only 
convey Information the user is likely to understand. 


For proceduress the status parameter Is required. Again 
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the conditions returned should be as understandable to the 
user as possibie. This is particularily important when 
there are muitiple procedure calis made within our 
software as the resuit of a single call by a user 
procedure. Emphasis should be placed on improving the 
status returned to the user rather than blindiy passing 
back obscure stetus from the depths of the systen. 


Detailed formats of the status variable are available tin 
the NOS/VE ERS. 


4.4.2 ERROR TERMINATION 


There are a number of errors that can occur in a aroduct» 
some of which can be detected and some of which can't, 
Tais section desis with the processing to be performed 
when detectabie errors occur. 


First of alls» the product should try to detect as Many 
errors as gracefully as possible. This means that 
internal software tests should be used to detect errors as 
well as using the condition handling facilities of the 
operating system to receive control In the event of a 
system or hardware detected error. The product cannot 
simply rely on the standard operating system abort 
processing. 

When an error {fs detected» the product should provide as 
much of the following error localization information as 
possibile. Some of the Information wili not be applicabie 
to all products. 


P Type of error termination (standard System messages 
should be usec for this message). 


° Full traceback of the call sequence to the Procedure 
containing the error. This wliil be by procedure name 
and tine number or relative address cepending upon the 
amount cof traceback/debug information reieased with 
the product. 


° Information regarding the user data being processed. 
For a compiler, this might be the procedure name and 
line number currently being processed. For a utility 
or data mansgement product, it might be the current 
record. 


* Optional duaps of useful internal tables. 


The above information should oniy be logged for error 
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terminations that sre probably caused ty product feilure. 
It should not te losged for conditions such as time Limit 
or operator drop which are clearly not product errors. 


40423 INTERACTIVE ERROR PROCESSING 


This section supplements section 4.2» "Interactive 
Processing". 


In considering this topic it is necessary to distinguish 
between error messages and diagnostics. These terms are 
difficult to define precisely but are Intuitively distinct 
nonetheless. An error message is generally a summary of a 
command; in an interactive environment it wants to be 
displayed at the terminal so the user can find out what 
happened. Diagnostics are generally a part of a larger 
whole (e.g.» Listeble cutput) which due to their volume 
oniy want to be selectively displieyed. 

An example is a comptier which provides a single error 
message telling hew many errors occurred during 
compliaticon and produces a diagnostic for each compilation 
error. 


4.4.3.1 Error Messases 


ae All error messages should be issuec via the standard 
mesSage generator. The message generator wiii 
determine whether the message should go to the 
terminal or the log» etc. 


be. Messages must be courteous. Feopie tend to react in a 
more emcoticnal fashion when using a computer 
Interactively than when using it In a batch mode. 
words such es “Itlegal*® shouidc be avoided in favor of 
words Iike “incorrect™ or "unknown". Error messages 
should explain to the users what they did wrong ands 
if possibies how te correct it. 


ce Messages must be meaningful such that an Inexperienced 
or casual user Is able to understand the messages and 
respond appropriately without reference to a manuel. 


de Any message jongé@r than twenty characters must have an 
aiternate brief counterpart. The user must be able to 
select elther the brief or the long form of the 
message. 
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64542342 Diagnestics 


a) 


b) 


Points b anc cy» ebCve alse appiy to diagnostics. 
Diagnostics shoulda explain the problem from the user's 
perspective rather than the program’s. For example: 


"Comma missing after third parameter" 
instead of 
WQVPPARSEPR detected Iilegsi syntax". 


While diagnestics are not typically displayed at a 
terminal by defaults they are looked at by Interactive 
users. This must be considered when defining the 
location of the diagnostics in the listings 
identifying the diagnostics with a mark that Is 
uniquely detectable with a text editor» etc. 


4o04.3e3 Inout_Diasoosis 


This section epplies to ali input that can reasonabiy be 
expected to come from a terminal (e.g.» command utility 
Subcommands). 


Be 


b. 


Ce 


de 


Errors in input will be diagncesed immediately 
following the incorrect input. 


Diagnosed Input errors must be correctable without 
exiting the dialogue with the program. 


Diagnosed input errors may be corrected without 
reentering the ertire line. 


Any input dlagnosed to the terminal must be 
correctable by terminal Input immediately following 
the diagnostic whether or not the original input was 
from the terminal. 


424.24 BATCH ERRGR PROCESSING 


e441 Error Messages 


Batch error messages should fcilow exactiy the same 
guidelines as interactive particularily the usage of the 
message generator. 
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4.4.4.2 Ingut_Dlagoesis 


The kind of user interaction that Is deslrable in 
Interactive mode Is of course Inappropriate in batch 
mode» Emphasis should be placed on detecting as many real 
errors as possible even after a fatal error has occurred, 
The key word here Is "real"; producing a large number of 
extraneous error messages or diagnostics will ultimately 
lead to peopie only correcting one probdiem at a time. 


424.5 TRANSACTION ERRGR PROCESSING 


This section will be added when mere design on the 
transaction facility hes occurred. 


40406 RESTART 


This section wiil be added when more design on the system 
restart capablitities has occurred. 


(403 EFFECTIVE VSt_ OF. Cis0 HARDWARE 
4.5.1 HARDWARE OPERATION 


This section describes software conventions which must be 
followed for the hardware to function in a prediciabie 
manner. 


4.5.1.1 Interlock Words 


Convention: Locste ali interiock words in cache bypass 
segnents. 


Special system instructions are provided In the CPU and 
the I0U to interiock muitiple processors/I0U. In generals 
these functlon by exchanging the contents of a register 
and a word in memory. Foliowting this exchange the 
register may be Investigeted to determine whether the lock 
has been set. For examples a zero word in memory can be 
selected to mean "no lock", then by exchanging a non-zero 
register the lock will have been set if a zero value is 
returned. It is imperative that such Interlock words be 
unique. To guerantee this they are placed in cache bypass 
segments. Notice that the Instructions which are destIgned 
to test and set locks automaticaily bypass cache. 

Problems arjse when the interlock words are accessed by 
other instructions such as loads. 
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&e5ele2 Pre-~serialization.of Clear_LlLock 


Convention: Befcre clesring a single bit tock (via e Stora 
Bit Instruction) first set the lock by a Test 
and Set Bit Instruction. 

Care must be taken whenever an interlock word Is set or 

cleared to pre-serlalize the operation. This is done to 

ensure that» in the event that memory references are being 
satisfied out of sequences all outstanding memory 
raferences are completed before changing the Iock. In 
practices, CYBER 180 systems designed to date always 
satisfy memory references in sequence. Howevers this may 

not always be the case. The instruction which sets a 

single bit lock (Test and Set Bit) performs the necessary 

pre-serializaticn. However» to clear the lock a Store Bit 

(wlth a zero operand) must be used. Since this 

Instruction hes a general utility it does not 

pre-serlalize. To compensates the Test and Set Bit 

instruction post-serializes. Hences to ensure a 

pre-serializaticn of the clear 10cky the lock should first 

be set (with a Test and Set Bit instruction), then cieared 
by the next instruction. 


4.5.1.3 Register Beservations 


Convention: Registers A0-A4 and xXC-X1l shall be reserved 
for special functions. 


The CYBER 180 instructions make use of certain registers 
to hoid given velues. The assignments are as follows: 


AO —- Dynamic Space Pointer (OSP) 


Al - Current Stack Frame Pointer (CSF) 
A2 ~- Previous Save Area Pointer (PFA) 
A3 - Binding Section Pointer (BSP) 

A4 - Argument List Pointer (ALP) 


These registers hold those vaiues by software conventions 
but a convention which Is supported by the hardware. 

Hences it is very important that they be supported by ail 
software procedures. In particulars, Ai and A2 must never 
be alitered by instructions other than Calis» Return and Pop. 


In addition to the reservations aboves registers XO and Xl 
have a special meaning in the hardware. For many 
Instructionss the XO designator is used to indicate no 
register. Hences register XO cannot be used by these 
instructions. Both XO and X1 are used as fixed utility 
registers for severai instructions. Examples are: 
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1) Load/Store muitipie and CALL Instructions use X6 
for a save erea descriptor. 

2) <All compare instructions return a vaiue to 
X1-Rights as does the Mark to Boclean instruction. 


3) The BOP Instructions opticneily use XO-Right and 
Xi-Right to hold operand lengths. 


Since these registers are used for special purposes, care 
must be exercised if they are usec in a general manners 


4251.4 Allanment_of.Tabies_and words 


Convention: Align certain tables and words on specified 
boundarles. 


Although CYBER 180 Is nominally a byte addressabie 
machines feal memory is organized into 64-bit words. 
Consequentiys, the performance of certain operations hes 
been optimized ty placing the operands on word 

boundaries.- The complete set of data alignments necessary 
is given belows alors with a brief description of why the 
alignment is reauired and what will happen when the deta 
js not allgned correctiy. 


4e5 016401 64-BIT WORD BOUNDARIES 
The following deta either must bes or should be aligned on 
Word boundaries: 


1) Process Segment Table - For performance reasons the 
hardware indexes into the 
Segment table at a worc 
boundary. The virtual memory 
address transtation mechanism 
witli fall if the segment 
table ts incorrectly aligned. 


2) Binding Sections - To maximize the reach Into 
the Binding Section by the 
Call Indirect instructlon» 
access is made to a word 
boundary. If the Binding 
Section is incorrectly 
aligneds then an Address 
Specification Error results 
when a Cail Indirect is 
Issued. 
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3) Procedure Entry Points - To maximize the reach of the 
Call Relative instructions a 
branch is made to a word 
boundary» Since the 
instruction forces the 
address to a word address» 
resuits wiil be unpredictabie 
if the procedure target was 
not correctly aligned. Note 
that even though It is not 

strictiy necessary for 
procedures cailed via a 
Binding Section to be word 
aligned, difficulties could 
still result if they are 
net. This is because the 
CYBER 180 Library Generators 
In the process of “bincding™ 
may convert Cali Indirect 
instructions to Call Reletive 
instructions. 


4) Debug List Entries - To simplify the hafdwares and 
to optimize performance shen 
in debug modes the hardware 
accesses debug list entries 
on word boundaries. 

Incorrect alignment will 
cause unpredictable resuits. 


5) Interlock Words - Interlock words used In 
conjunction with the 
Compare/Swap operation must 
be aligned on a word 
boundary. This is necessary 
for the processor to satisfy 
the ron~preemptive 
requirements of the 
instruction. Processors 
utilize the 64-bit memory 
exchange function in this 
operation. That function 
operates on areal memory 
worde Incorrect alignment 
will yield an Address 
Specification Error. 


6) Stack Frames - By software cOnvention onlys 
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Stack frames should be 
aligned on word boundaries. 
This enables the hardwere to 
load and store the registers 
heid In the save area from. 
date on word boundaries. 
Incorrect alignment will not 
cause any problems since the 
hardwere always adjusts 
(forces) the Dynamic Space 
Pointer to a word boundary 
before accessing a stack 


frame. 
7) Central Memory Data ~ The I0U can only reference 
Accessed by the 10 cantral memory words. Hences 


it would require some special 
code in PP*%s to decode data 
not stored on word 
boundaries. This is reaily a 
pragmatic software convention 
since a PP has no way to 
specify a centrai memory 
address other than on ¢ word 
bouncary. 


Geb ele4e2 OTHER BOUNDARTES 


Tne following data must be allgned cn boundaries other 
than 64-bit worse or 8&-bit byte. 


{1) Exchange Peckages - 123-bit (2 word) Boundaries 


To optimize the performance of the exchange jump on some 
processors» the hardware addresses two words at one time. 
Results will be uMPredictable if the exchange package is 
Incorrectly aligned. 


(2) Instructions - Parcel (2-byte) Boundaries 


Instructionss which ere either 16-bit or 32-bit 
quantities, must te aligned on parcel boundaries. 
Failures to do this will either result In unpredictable 
behaviors or an Address Specification will be detected, 


{3) Page Table - Page TsbjJe Length Boundary 
To minimize the time needed to transiate addresses from 
virtual to real» the hardware catenastes (rather than adds) 


4-32 
CYBER 180 System Interface Standard 
86/02/04 
4.0 SYS TEMWIDE CONVENTIONS 
4o3e10422 GTHER BOUNDARIES 


the Page Table Addresses {PTA) to the page table Index. 

For the catenation to yield the correct address» the 

low-order bits of the PTA» as determined by the page table 
lengths must be zero. Failure to structure the PTA in 

this manner will cause the address translate mechanism to fall. 


4.502 HARDWARE PERFORMANCE 


Wheress the previous section dealt with conventions 
necessary to make the hardware work correctiys this 
section deals with conventions necessary to make the 
hardware work efficiently. As such they are not 
mandatory» and in some cases represent merely suggestions 
as to how to optimize certain functlons. 


4.52221 Locality_of Reference 


Convention: Piace ali code and all data to be used at one 
time in one piaces and keep to a minimum the number of 
segments required to execute a given task. 


The CYBER 180 virtual memory organization provides the 
basis for the system security and simplifies the explicit 
oryanizetion of a program Into overlays. Howevers eli 
programmers have responsibilities if system throughput is 
to be optimizec. A prime responsibility Is to maintain a 
strict locality of reference. That is collect ali code 
and ali data thet Is to be used at one time into 
contiguous pages in one segment ‘leach for code and data). 
This has two advantages» it minimizes the working set (the 
number of pages allocated in real memory at any given 
point of time)s and it aiso minimizes the number of 
entries which must be made in the buffer memories. By 
minimizing the working set the number of concurrent tasks 
which can be held in real memory is maximized. This» in 
turns maximizes system throughput. 


Optimizing around the buffer memories fepresent a slightly 
different problem. These have a finite size and contain 
the most recentiy used Segment Descriptor Entries and Page 
Table Entries. If a Sarge number of segments are in use 
at one times or if a large number of pages are in use at 
one times then the buffer memorles wili be unable to hold 
all the necessery entries and they wiil be constantly 
loading new values. The affect will be similiar to not 
having them at 61! and performance will degrade 
considerably. 
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Consequently» not only should programmers Maintain e 
locality of references but they should aiso try to 
locsiize the number cf seyments usec by a given task. 


425.202 Reglster_Allosation_and_Usase 


Convention: Allocate A-Registers and X-Registers from the 
small numbers on upe 


As a result of the special functions For which A0—A4 and 
XO-X1 are used» and the method of saving/restoring 
contiguous registers by the CALL/RETURN instructions, 
register usage should always start with the smallest 
possibie number (typically AS and X2). This will help to 
minimize the nunber of reyisters xhich must be saved 
across procedure calis. Thiss in turns will optimize 
performance in this area. 


e503 SECURITY 


This section lists software conventions needed to provide 
@ secure environment at ali times. Since a major 
objective of the CYBER 180 program is to provide a highly 
secure systems these conventions become mandatory. These 
conventions are closely related to thoSe in Section 2, 
Just as they are required to make the hardware operate in 
a corrects predictabie manners so sare these required to 
guarantee that the security and protection algorithms 
function correctly. 


4.5.3.1 Procedure Parameters 


Convention: 1) Always use calier's argument jist polnters 
for accessing caller's data. 


2) Always toad pointer parameters directly 
into A-Reylsters - via Load A instructions. 


3) Whenever possible avoid moving record 
structures that contain pointers. 


4) Avoid passing pointers between rings 
elther way. 


5) Avoid data structures containing direct 
pointers that cross rings either way. 


These conventions are mandatory for those procedure calls 
From one procedure to a second one with more privilege. 
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when a procedure Is calied by another procedure, it 
executes on behalf of the caller. It is the 
responsiblliity of the cali2ee to ensure that it does not 
execute with mcre privilege than calier. The hardwere 
provides the basic security mechanisms. In this cases it 
ensures that cellee is calied from within its call ring 
brackets and that It Is called vie a Binding Section. It 
may then access code and data belicnging to or accessible 
by caller. This code and data is referenced via pointers 
held tn A-Registerss and the hardware performs a ring 
number vote whenever an A-Register is toaded. This 
mechanism ensures the least privilege (highest ring 
number) Is always accorded the user. However» there are 
many ways this mechanism can be be-passed. The simplest 
methed Is for cettiee to toad a pointer into an X-Registers»s 
then copy it to an A-Register. If calier places a low 
ring number (zero would do) in the pointers then it will 
end up with cattee'ts ring number in the A-Register. That 
Is It will end up with more privilege than that to which 
caller is entitled. It is callee's responsibllity to 
ensure this does not happen. The onus for maintaining 
security always felis on the more privileged procedure. 
Hencey the convention. 


4.6 SUPPORT_OQF_EBCOIC DATA 
EBCDIC data can be divided into two distinct classes: 


le al! 8—bit character data (also known as coded deta, 
Including unpacked numeric data types); and 


Ze intermixed character and non-character data. 


Support for the former (ail character) is provided by the 
operating system. If EBCDIC is specified on the request 
cards, the tape driver automatically transiates to ASCII 
wnen reading the tape end transitates back to EBCDIC when 
writing the tape. 


Support for the Yatter (intermixed character and 
non-character)», and for the EBCDIC collating sequence» 
varfes by product: 


rawoan 
os i 
Wy WON 
=N“ OM 

a we) 
OOM Mw EO 
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EBCDIC SuPPORT N 
Intermixed EBCDIC input file e x 
Intermixec EBCDIC output file e x 
EBCDIC collating sequence x x X 


X = support requiréd at R1 of product 
€ = eventual support desirable 


Support of intermixed Input and output files means Use of 
the special C18 instructions to process the following 
"translated" non-character EBCDIC deta types: 


° Binary (signed and unsigned) 
® Packed Decimal (signed and unsigned) 
407 KEYRQINT_USAGE 


The CY180 keypoint faciiity provides a mechanism to enable 
collection of statistics for performance monitoring. A 
data reduction software package is avaliabie to summarize 
these statistics based on descriptors contained in a 
keypoint descriptor fille {KDF). This section ducuments 
the conventions to be followed by the operating system and 
product set In the usage of this facility. 


42701 KEYPOINT CLASSES 


Five keypoint classes named ENTRY» EXITs» UNUSUAL» DEBUG, 
and DATA are defined for the operating system and Product 
set. 


ENTRY Every geted procedure plus all maJor 
internal procedures (those shared across 
functional areas) should contain a 
keypoint of this cless. These keypoints 
should be placed as close as possibie to 
the entry to the procedure. 


EXIT Every gated procedure pius ali major 
internal procedures (those shared across 
functional areas) should contain a 
keypoint of this class. Thase keypoints 
should be placed as close as possibie to 
the exit from the procedure. 


Aiea ge aah sada ‘lh A ag OR CN Re ee a 
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UNUSUAL Every situation which is unexpected or 
auite unusual should contain a keypoint of 
this class. It is intended that these 
keypoints would be enabled at ail times. 
The freguency of encountering these 
keypoints should be very low. The DATA 
keypoint class is not allowed In 
conjunction with a keypoint of class 
unusual. 


DEBUG These keypoints would be for providing 
additional trace information as an assist 
In debugging of hardware or software 
problems. DEBUG class keypoints would be 
most useful in the more compiex areas of 
the system. The primary use of keypoints 
in HCS and NOS/VE up to this point has 
been for debugging purposes. 


DATA This keypoint class can be used with the 
ENTRY» EXITs and DEBUG keypotnts for the 
gathering of axtra datae Ali DATA 
keypoints encountered are supplying 
additlonel data which will be associated 
with the last ENTRY» EXIT or DEBUG 
keypoint. Hences they should follow as 
closely as possible after the ENTRY» EXIT>s 
or DEBUG keypoint; in particulars there 
should be no Intervening CALL 
instruction. DATA keypoints should be 
usec with care since the PMF hardware can 
oniy buffer up 16 keypoints; keypoint 
clustering can cause Jost keypoints. 


Keypoint Data and Identification: 


Upon successful execution each keypoint instruction will 
provide a total of 32 bits of Information. The convention 
uses 12 bits of this for keypoint Identification and the 
remaining 20 bits as user supplied data. Try to use this 
20 bits to provide meaningful information {taskids segment 
numbef,s, fileids queue jiengths, page numbers times etc.). 

On DATA class keypoints the data belongs to the previous 
keypoint and the full 32 bits is avaliable for additional 
user data. 
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4.7elel Operating _systen 
The keypoint classes fOr NOS/VE afe as foliows: 
OSCSDATA=0 
OSCSUNUSUAL=1 
OSCSENTRY=2 
OSCSEXIT=3 
OSC SDEBUG=4 
Keypoint class 5 is reserved for NOS/VE. 
The operating syStem keypoilnt muitiplier is OSK$M-. 
4e7ele2 Produst Set 
The keypoint classes fOr the product set are as follows: 
PSCSCATA=6 
PSC SUNUSUAL =7 
PSCSENTRY=€& 
PSCSEXIT=9 
PSCSDEBUG=10 
The product set keypoint multipiter Is PSKSM. 
4.7.1.3 Otherc_Classes 


The keypoint classes 11-14 are reserved for userse 
Keypoint class 15 is reserved for PMF hardware control. 


The keypoint muitipiier for user defined keypoints is OSKSM. 
4e7e2 KEYPOINT IDENTIFIERS 


A maximum of 65535 keypciInt Identiflers are avallable for 
(each) NOS/VE and the product sete The combination of 
keypoint class and Identifier is unique within the system. 


4.7.2.1 OQperatina_Systen 


The set of 4096 available identiflers is assigned to operating 
system areas in blocks of 50. Some areas (if needed) will receive 
two consecutive biocks of 50. The NOS/VE performance project has 
responsibility for assigning the ranyes to areas of the operating 
systeme 


SG BH 26 CE GY ae Oe BE 
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The currently essigned values for the cperating system are: 


Area Identifier Range 
{not used) 0 - 4S 
AM Access Method 50 - 149 
BA Basic Access Method 150 - 249 
CL Command Language 250 = 299 
cM Configuration Management 300 — 349 


(future expanslon) 


DM Device Management 400 - 549 
(future expansion) 
Ic Interstate Communications 600 - 649 
IF interactive Facility 650 - 699 
Ii Interactive Interface 700 - 749 
(future expansion) 
JM Job Menagement 800 —- 8495 
LG Logs 850 - 3899 
(future expansion) 
io Loacer 950 - 999 
(future expansion) 
ML Memory Link 1050 - 1099 
MM Memory Menagement Monitor Mode 1100 - 1149 
MM Memory MaNaegement Job Mode 1150 - 1199 
MS Maintenance Services 1200 - 1249 
MT Monitor 1250 - 1299 
oc Cb ject Code Utility 1300 - 1349 
OF Cperator Facility 1350 - 1399 
OS Dperating System 1400 - 1449 
(future expansion) 
PF Permanent Files 1500 - 1599 
{future expansion) 
PM Program Management 1600 - 1699 
RH Remote Host 1750 - 1799 
SR Conversion Services 1800 - 1849 
ST Softwere Tools/Set Management 1850 - 1899 
™ Task Management Monitor Moce 1900 = 1949 
™ Task Menegement Job Mode 1950 — 1999 
JS Job Swepper Monitor Mode 2600 — 2049 
J5 Job Swepper Job Mode 2050 - 2099 
AV Accounting Validation 2100 - 2149 
SF Statistic Facility 2150 - 2199 
Ic Input / Output 2200 —- 2249 
(future expansion) 
DM Device Management/ Tape 2300 - 2349 
ST System 2350 - 2399 
NA Network Access Method 2400 -— 2499 
NL Network Access Method 2500 - 2549 


NL Network Access Method 2550 - 2599 


BH SH CH 6 BO BH Ge GE CE GE GH BE CE GH HE HE BH UE HE BO SH BH BH CO HH OH HE CGE HE GH OO BH OH CH BH BE BE OE HH EE OH GH BO OH BE OH Be ae BE 
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(future expansion) 


FM Fille Menagement 2700 ~ 2799 
FS File System 2800 - 2899 
RM Resource Management 2900 = 2999 


NA Network Access / Monitor Mode 3000 - 3049 
{future expansion) 
MT Monitor 4000 - 4049 


ie 26 He SO BH BH BO 
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The keypoiInt recuction utility and the continuous monitoring 
facility depend upon the following keypoint values. These routines 
should be modified to use the keypoint names and not the keypoint 
values listed below. This modification shouid be completed by 
NOS/VE release 1.2e1 (second quarter 1986). 


4001 Enter / Exit Monitor Mode mtk$joblentryTlexit 


4002 Enter # Exit NOS 170 mtk$i70_entry_exit 

4903 Monitor Mode Trap Handler mtk$monitor_mode_trap 

4004 Job Mode Trap Handier mtk3job_mode_tr ap 

2200 Series Physical 1/0 

1106 Page Fault Processor mmktpage_ fault 

1149 Convert PVA to SVA mmkSsystem virtual address 
1906 Queue Task tak$queue_ task 

1918 Switch Task tmk$switchotask 


%e7e2e2 Product Set 


The set cf 65535 availiable identifiers is assigned to products 
in blocks of 5C. Trose product set members which require more 
than 50 will be assigned one or more additional blocks. 


Se SE BH BH B26 CH OE BE BH HO Be 6H HE Be GH 
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Assigned ranges are: 


Product Identifier Range 

{invalid) 0 
AA Advenced Access Method i- 49 
AP APL 50 - 99 
BC BASIC 100 - 149 
cB COBOL 150 - i99 
DB Interactive Debuy 200 -= 249 
FC FORTRAN Compiler 250 - 299 
FL Fortran Run-Time 300 = 349 
FM Fiije Menagement Utility 350 - 399 
FT FORTRAN Giobal 400 - 449 
IM Information Management 450 - 499 
PA Pascal 500 - 549 
Pi PL/I 550 = 555 
QU Query Update 600 - 649 
SM Sort/Merge 650 —- 699 
SV Shared Variables Processor 700 - 749 
cc Common Compiler Nodules 750 - 799 
CG Common Code Generator 800 - 849 
(future product) 850 - 899 
ML Math Library 900 - 949 
CY CYBIL 950 - 999 
$c Source Code uUtllity 1000 - 1049 
AL Assembler 1050 - 1099 
FA File Migration Aids 1100 - 1149 
LI Lisp 1150 - 1199 
AD Ada 1200 - 1249 
FY Coc Fortran 1250 - 1299 
Vx VX/VE 1300 - 1349 
vc C compiler 1350 - 1399 
PT Performance Tools 1400 - 1449 
KR Keypotnt Reporting Utility 1450 - 1499 
NF Network File Transfer 1500 - 1549 
(Reserved for future products) 1550 - 1999 


AA Advanced Access (2nd block) 2000 - 2049 
(Reserved fer future products) 2050 - 65535 
4.7.3 KEYPOINT USE 
From a software point of views keypoints are special 
commands that are inserted in a medule according to the 


quidelines specified in section 4721+ For a module 
written in CYBIL»s the #KEYPOINT intrinsic can be used to 


“ee Be 
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generate the keypoint instruction (refer to CYBIL Language 
Specifications ARH22985 and MIGDS» ARH1700» for deteiis). 


The main entry keypoint identifying a product set member 
should include cata which indicates the actual version of 
the product. This is useful for tracking simultaneous 
execution of the same cr different versions of a product. 
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500 COMPILER AND ASSEMBLY CODE CONVENTIONS 


This standard is to be felilowed by the object code 
generated by the compliers and by any assembler coce 
written as part of standard softwere. 


In addition to these standards, asSembler code 
(nandwritten of compiler generated) wil! conform to the 
coding standards described in CYBER 180 MAINTENANCE 
SOFTWARE CODING CONVENTIONS (DAP ARH2160). 


5o1 USE_OF LOADER FEATURES 


l. 


3e 


The loader specification is timited to thet written in 
its formal documentation. Programmers shail not 
depend on additional characteristics determined by 
empirical observations as such behavior may be subject 
to change. Examples which have caused trouble on 
CY170 are the presetting of undefined varfiabies», the 
order of ftoeding from a Jibrarys and the address at 
which the first code is loadec. 


Runtime routines shali not limit the program 
structures cof thelr users. Gn CY17C ali CRM 1 
routines must be In the root segment of a segmented 
load» and CMM must have at least one routine in the 
main overiay of an overlaid program. Such 
restrictions must be avoided on CY1380. 


The following table shows in which sections particular 
types of data should be allocatedy and the attributes 
the section should have. 


Attributes R = reads W = writes B = Binding and 
—E = execute. 


Section 
Data Type Tyre Att Comment and Examples 
"Static Working RsW Ali variables not 


alfocated on the stacks in 
common or explicitiy 
allocated to a sectione. 
Includes FORTRAN local 
verlables»s CYBIL [STATIC] 
and (XDCL] veriables. 


Constants{1) Working R Ali iiterai constants 
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which for reason of 
indirect addressing or 
iength cannot be expressed 
directiy in the code. 


Constants(2) Code E Optionally, constants as 
In (1) which are iess than 
8 bytes iong and 
convenientiy accessed 
through the LBYTP 
instruction. Note that 
the "constant" may not be 
a PYA. 


*XREFY Binding 8 Data declared in another 
unit of compilation are 
usually referenced through 
peinters placed in the 
binding section by the 
joader (rather than in 
user sections indirectly 
referenced through the 
binding sections where 
they would be inaccessible 
to the binder). 


Heaps common 
extens- 
ible RaW For the system heap see 
section 5 e%e3 Other 
heaps are deciared In 
CYBIL. 


4. The folloring action should te taken if a compiler 
detects a fatal error in the source code it is 
compilings untess the compiler was called with 
“CEBUG=0C" (see section 242): 

An IDR record shai! be issued containing the string 
"errors in compilation" 


in the comment fieicd. The non-executabie attribute 
shal i be set. 


If CEBUG=DC was selecteds the compiler shali continue 
normal processing as far as possible. 


Be Ald compilers shoutd emit loader names (common bicock 
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names» XREF names» module names» etc.) using wpper 
case alphabetic letters when ietters occur in the 
names. An exception to this rule is made for any 
language which recuires the distinction between upper 
and lower case names. 


52 INTERLANGUAGE CALLING SEQUENC £5 
Purpose 


The purpose of the Interlanyjguage calling sequence Is to 
faciiitate inter-language procedure calls. This Is 
particularly desirable on CYBER 180 because of the system 
level support for sharing of code between executing 
tasks. For exampies it would be desirabie to have only 
one set of mathematical routines to be used by ail 
languages. 


Restrictions 


Ali CYBER 180 Compilers must be capsbie of generating the 
CYBER 180 interianguage Calling Sequence for an externally 
referenceable code mocguie. It is a geal in the definition 
of this calling sequence that It be useable by the 
majority of the compilers as a subset of their standard 
calling sequence. It obviousiy cannot meet all of the 
needs of languages as diverse as BASIC and PL/I. [t would 
be acceptable (but certainly not preferable) if a 
particular language were to require speciai declarations 
or attributes on e procedure call to cause the generation 
of this calling sequence. 


It is expected thet users in the various progremming 
languages may have to take additionel steps with respect 
to data declarations to guarantee that the allgnment and 
packing corresponc to that specified by this Interchange 
standard. The user Is also responsible for the values 
passed via this calling sequence. For examples a Boolean 
variable might contain values 0-7 (since it occupies a 
byte) but the common calling sequence only assures 

inter language capability for the values 0 and 1. 

In generals» a compiler may employ any calling sequence it 
chooses between itself and its library or non-externatl 
procedurese Exceptions to this will be for routines which 
can be of general use to many languages (@eGes math 
library routines). Such routines may haYe a fast calling 
sequence but must alSo provide an eantry point conforming 
to the interlanguage calling sequence. 
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§5e2e1 CALLING SEQUENCE FORMATS 


The Interlanguage caliing sequence is defined to Include not only 
the tayout of the parameter list, out aiso the fayout of any 
descriptors associated with parameters In the list. Two formats for 
the Inter language calling sequence are avaliable. The term. 
"interlanguage célliing sequence™ is tsed to refer to these two 
formats collectively. Two different formats are required in order 
to provide flexibility of usage from language to language while not 
unreasonably degrading eerformance end usability. These two formats 
will) be referred to as the "System™ and "General™ formats. | 
el to either of these formats may be made vila ae DAP against 

the SIS. 


The calling sequence provided by a complier for use between Internal 
precedures and functions known to be written in the same language | 
Need not conform to either format of the iInterlanguage calling 
sequence. Additioneliy there Is no requirement to use the 
Interlanguage cailing sequence between compiler generated procedures 
and functions and any assembler procedures and functions provided in 
a runtime library specific to that ianguage. In generais assembier 
procedures and functions are responsible for accepting a parameter 
list Format of the kind generated by their potential callers... 
However calls to the scaiar CMML call-by-reference procedures and 
functions must conform to the System formats, while calis to the 
vector/array CMML call-by-reference procedures and functions must | 
conform to the Genefal format. 


5e2eiel Kinds.of Parametercs 


For purposes of expcsitions six kinds of parameters will be 
distinguished: simple value parameters, extended value parameters» 
simple reference parameters, extended reference parameters» simple 
bit reference parameterss and extended bit reference parameters.. 


Value parameters ere those parameters for which a vaiue Is intended 
to be passed, The caliing program can assume thet the actual 
argument it passes wili not be changed by the called program. Note 
that this does not imply a specific impiementation techniaue 
{several are possible). Some value parameters aiso require that 
certain descripter Information must be passed atong with the value. 


Simpie value paremeters are those value parameters Which require 
only a vaiue to be passed to the calied routine. 


Extended value parameters are those value parameters which are 
composed of a vaiue pius 4 d@scriptor. Included in this category 
are pointers-to-PrOcedure when they are accompanied by 2 static 
link. 


oe Ge Be Be BO Hu 
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Reference parameters ere those parameters for which an object Is 
intended to be passeéd. The calling program must assume that the 
actuai argument it passes may be changed by the caited program. 
Note that this does not imply a specific implementation techniques 
although at ifiesst an address must normally ba passed. Some 
reference paremeters also require that certain descriptor 
Informaticn must be passed along with the address. 


Simple reference parameters are those freference paerareters which 
require only en address» or only an address pius ai string 
descriptors to be passed to the callirg routine. 


Extended reference parameters are those reference parameters which 
are compesed of an address pius a string descriptor plus 4 
non-string descriptors cr of an address pius a non-string | 
descriptor. 


Sitmpie bit reference parameters are those reference parameters which 
require only an address plus a bit string descriptor plus a bit string 
offset to be passed to the caliing routine. 


Extended bit reference parameters are those reference parameters which 
are composed oF en sddress plus a bit string descriptor plus a bit 
string offset plus @ non-string descripter. 


5e2ele2 System Format_of the loteclanguagge Cailing Seauence 


This format is the one used by the system implementation language 
(CY8IL)» and ald operating syStem interfaces. This format is 
documented In detail in section 5.220521 of the SIS. 


5221.3 General_cormat_of_ the Interlanguage Calling Seguensce 


This format Is more general than the system format. It will be used 
by Ade and CDC FORTRAN. This format is documented in detalii in 
section 5.2.5.2 of the SIS. 


5e2ele4 Summary. of Format Differences 


The primary difference between the System and General formats is in 
the placement ane content of descriptorse System format and Genera 
format actual parameter lists are identical if only simple reference 
parameters are pessed. Atl System format descriptors are placed 
directly in the parameter list following the PVA of the object being 
described» while Generai format non-string descriptors are placed 
outside the parameter tJist. The General format parameter tist 
contains the PVA of the descriptor as well es the PVA of the object 
being described. 
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The System format does not support extended value parameters 

except for pointers-to-procedure. For simple value perameters» 

the System Format and the Generasai Format are identical except when 
the value parameter is iess than one word in size. The General format 
requires that the value parameter be right aligned with sign fill on. 
the jeft for integers end subranges of integers end zero fill 
othearwises while the System format requires right alignment but does 
not define the fill bits on the left. 


Use of the General format of the Interlanguasge calling Sequence 
reauilres that a “big"™ {i.e. tonger than a word) value parameter 
which is passed via a pointer will have been copied by the caller. 
The passed peinter Is a pointer to the copys ena the calied program 
is free to write into the memory pointed to. The System format does 
not specify whether or not a "big" yvaitUe parameter will have been 
copied by the callers so in this case the called prograr should not 
write into the memory pointed to. 


Se2ele5 Calls Potentialiy from Another. Lansuage 


Any procedure or function which is intended to be ceilabie from an 
external moduie potentially written in another tanguage should 
accept for that call one (or 2a subset of one) of the tuo formats of 
the Interlanguage celling sequence. Each compiler must document 
which of the two sequence formats it accepts» or state that none of 
its procedures and functions are externally callable from another 


language. 

Languege Interlanguage Format Accepted 
ADA General Format 

BASIC “not interilanguage calilabie- 
Cc ~to be determined- 

CGBCL System format 

CYBIL System formet 

FORTRAN General format 

Pascal —-not interlanguage cailabie- 


522.126 Calis Potentially. to Another Language 


A compllier may assume that no call it generates is an interianguage 
call uniess the author of the source program has explicitiy 
indicated that a particular cali is interlanguage. This means that 
each tanguage which supports calis to moduies written in another 
language must provide a mechanism within the sOurce language with 
which the author of the source program can explicitiy Indicate that . 
a particUler call is interlangusege. This mechanism must be 
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formulated such that the author ts further required to state 
explicitiy (by neme)d which other language is being cesited. It is 
then up te the complier to generate the correct interlansuage 
caliing sequence for the cajil. Thus the complier must know sahich 
languages accept which calling sequences. It remains the 
responsibility of the authors not the compilers, to ensure that the . 
actual and formal parameters of the cali are compatibie. The 
compifter haS the responsibility to generate the correct jtayout for 
the parameter list and parameter descriptors» as expected by the 
called language. 


These provisions do not require a complier or language to provide 
Inter language celis, but they do define restrictions on how 
inter language caiiing Is to be supported. A tianguage may support 
Interianguage cails to only a limited number of other jlanguagess If 
it so chooses. Note thet even If a language supports direct | 
Interianguage calis,s, It is not required to also support Indirect 
interlanguage calls via dereferenced pointers-to-procedure. 


Se2elebel SUPPORT FOR CALLS TO ANOTHER LANGUAGE 

If a language? supports cafis to modules written in another languages 
and that other tlanguege accepts calis with simple reference 
parameters, then the celling language musts» at the minimums support | 
calls with simpie reference parameters. A string d@éscriptor must be 
supplied for any cbject which takes ones unless the seuthor cf the 
calling program hes explicitiy indicated that no string descriptor 
need be passed. An explicit indicetion is possibie in ifianguages» 
such as CYBIL» which allow the reference parameter in an external 
procedure dectaretion to be specified as either fixed type 
(descriptor need not be passed) or adaptable type {descriptor must 
be passed). 


The calling tanguage Is strongly encouraged to also provide support 
for calls with velue peremeters and extended reference parameters if 
the called language accepts such cajlis. This support would consist 
of a mechanism within the source language to exp§icitiy Indicate, 
for each actual perameter of the iInterianguage calis whether the 
parameter is to be passed by value» by simpie references or by 
extended reference. The compiler then has the responsibility to 
generate the appropriate calling sequence, 


5e2e2 CALL 
The procedure call instruction CALLSEGs, Reference #115 as 


dafined In the CYBER 180 MIGDS will be used to perform the 
procedure cail. 
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5e2e3 REGISTER SAVING CONVENTIONS 
For generalized external calls and calis to formal 
procedures, the compiler may not assume thet the catied 
procedure will save and restore registers. <Any registers 
to be saved must be saved on the stack using the save 
mechanism of the CALL instruction. 
Internal calls need not use the CALLSEGs Reference #115 
Instruction. They may use CALLREL Reference #116 of any 
other code sequence which meets their needs. For internal! 
calis the compiiers have the opticn whether to save 
registers or net. Internal calis include calls to: 
a) the complier*s own library routines,» 
b) nested procedures within the same Compilation units 
5e.2e30e1 Loformatico_Besuirced.Across Calli 


The following information may be fequired in making a cali. 
Some of the intformaticn is not aiways required —- See footnotes. 


Dynamic to Caller and Cailjee 

* basic stack control registers {A0Qs Als A2)*** 
° parameter list pointer (A4)*#% 

* static chain/displ ay* 

s binding section pointer (A3)*** 

* product defined information 

Dynamic to Caliees Static to Caller 

* line number of call (see traceback section) *** 
° number of perameters(X0» bits 32-47) **+* 

° descriptor erea indicator 

° descriptor erea pointer (if any) 

Static to Calier and Cailee 


* name of caliee (see traceback section) 
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7 size of display/nesting depth*, ** 
e frame size/language** 
* type of frame; €.9. proc» funcs co~proct* 


* Block structurec languages only. 
** Traceback mode only. 
*** Raguired on caiis mede with the Interlanguage calling sequence. 


5 e204 FUNCTIONS 


A function is @ procedure that returns a value. The 
function vaiue is In the registers or In memory depending 
on the type of value beiny returned. Since function 
raferences are usualiy part of another expression that is 
being evaluated», it is generally desirable to have the 
value returned in a register. 


If the function value is a pointers then the vaiue is 
returned as a PVA In AF.» A procedure calling a 
pointer-vailued function must not save register AF on the 
call. A pointer-valued function may have the ring number 
fleild of AF altered by the RETURN instruction If it is 
eailed across aring boundary. 


If the function vaiue is a scalar of known length less 
than or equal to 64 bits in lengths it is returned right 
aligned in XF. A procedure calling such a Function must 
not save register XF on the call. 


If the function value is double precision or complex then 
the value {ts returnec in registers XE and XF. xXF holds 

the feast significant 64 bits of the value. <A procedure 
calling such a function must not save XE or XF on the cail. 


If the function value is non-scalar then it is stored at 
the address defined by the first element of the paremeter 
list. The second element of the parameter list specifies 
the first actual parameter. 


A scalar function resuit is defined as follows: 


e CYBIL - characters boolean, Integers ordinals» 
subrengess ceils pointer. 


° FGRTRAN - fJogicalys integer» reais double precision, 
compiexs, FORTRAN boslean.* 
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° COBOL - comps comp-l» comp-2, boolean. 


° PL/I - Integer(FIXED REAL)» real(FLOAT REAL)» 
complex{(COMPLEX) 
e BASIC - eal. 


integers (enumerated types sub-range)>,s 
reali 


® Pascal 


Scalar function values ere returned right aligned in the 
result register. FIli (1F any) ts zero bits. Note that 6 
byte numeric items reauire no fill. 


* FORTRAN boolean corresponds to a fuil CYBER 180 word without 
type. it is not the same as the bOolean type mentioned 
elsewhere in this Section. 


5.225 PARAMETER LIST 


The parameter list is allocated on @ word boundery in memory. Each 
entry in the perameter list must also begin on a word teundary. On 
entry to the callees register A4 will point to the paremeter list. 
Bits 32-47 of register <xX0O will! contain the number cof parameters 
{including the pseudo perameter for non-scalar valued functions). 
If the procedure being called is a function whose velue is to be 
returned in memorys the first element of the parameter list defines 
the fjocation at which the value Is to be stored. If no p@rameters 
(nor pseudo parameters) are to be passed, then the contents of A4 
are undefined and x0 must specify zero parameters. Under certain 
circumstances detalied belows a flag word must immediately precede 
the first word of the parameter list. 


5o2e5e1 System Format Parameter List 


{This is currentiy documented in the CYBIL HaNdboOok, DCS# ARH3078>» 
sections “CYBIL CisII TYPE AND VARIABLE MAPPING® (old section 7.1) 
and "RUN TiME ENVIRONMENT" subsection “PARAMETER PASSAGE™ (old 8.3). 
The following addition must be made to that documentation in order 
to conform to the SIS] 


For any potentieily iInterlaNguage call in which a System format 
actual persmeter list is passed that contains oniy simple reference 
parameters: The parameter iist must be immediately preceded by a 

flag word whose value Is the 64-bit Integer zero. The string 
descriptor must be included for any object which takes ones uniess 
the author of the source program hasS explicitiy indicated that It 
need not be pessed. These restrictions are made to insure 
compatibility between the reteasé 1.1.2 product set calling 
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Be cede? 


Del etele 


conventions and those for al! future releases. A fiag word need not 
precede any other System format actual parameter lists. 


General_Eormat Perameter_ List 


The General format parameter JISt must always be preceded by a fiag 
word. The parameter tlist itself is composed of two parts. The 


first part has exactly one word for each parameter (Including the 


pseudo parameter for non-scalar vaiued functions). If the fiag word 
oreceding the paremeter list is zero then only this first part Is 
presents otherwise the second (extension) part must also be present. 
This parameter List extension follows immediately after the first 
part of the parameter tists» and has exactly the seme iength in 
words. There is @ one-to-one correspondence between word j of the 
first part and word j of the extension. 


The parameter list extension is required if and only if one 

or nore of the actual parameters is an extended value perameter 
or an extended reference perameters or a {simple or extended) 
bit reference paremeter. 


1 FLAG WORD PRECEDING PARAMETER LIST 


The flag word immediately preceding a Generai format ectual 
parameter list must be present for any potentialiy interlenguege 
cali. This flag word has the following internal structure: 


record 
F1l2 O«.CKFTFFFFFFFFTI16)» 
f22 0,..0fFF(16)> 
f3: 0..-CKfFI16)>» 

recend 


Fleild f1 must etways be set te integer zero. It is reserved for 


future uses. Flieid €2 hes a language dependent values but may be. 


nonzero only if field f3 is nonzero. Field 3 must be set to 
Integer zero if the parameter iist extension Is absents and must be 
set to integer one otherwise. Any tanguage accepting cails 
according to the General format must accept interlanguage caijs for 
which fleic f2 Is zero. An tInterlanguage calier wil! never be 
required to set field f2 to a non-zero value. If fleid f2 Is set to 


a non-zero value for an interlanguage calls it is the responsibility | 


of the caller te set the fieid according to the expectations of the 
callee. 


eh ea 
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Se2e5e202 GENERAL FORMAT SIMPLE VALUE PARAMETERS 


If a slmpie value param@ter Is greater than one word In length and is 
not a pointer-to-procedures then it is passed using an identical format 
to that for a reference parameter. 


If a simple value parameter Is a pointef-to-procedure then the first 
part of that parameter list entry must contain the left justified PVA 
of the Code Base Pointer of the procedure in the binding section. The 
second part of the entry (when an extension is required) must . 
contain the NIL pointer. The 16 bits to the right of each of these PVAS 
is unused and undefined. This can be diagrammed as: 


Fe ee A Ne A A EO cae ee a ste De ee 

: PVA (Code Base) ; undef 3 3 NIL ; undef ; 

$e wee nee ee ee ee ee ewe wee + poe en ee ewe ee cee eee eee oe + 
If a simple value araweter is less than or egual to 3a word in tength» 
then a copy of the value Parameter is piaced directly in the first |. 
part of the parameter fist right aligned in @ words with sign fill on 
the left for Integers and subranges of integers and zere fili otherwise. 
The associated word in the second fart {when an extension Is . 
required) is unused and undefined. Note that if a PVA having ac. 
associated descriptor is passed by value, then by this rule the PVA 
is placed directly In the paramet@r lists right aligned in a words 
with the word zero-flifed on the ieft. This can be diagrammed as: 


Sp ee ee oe oe oe ee ee ee ee on oe ee a ee ee +> a eo 


H eaiue (right justified) H H undefined ; 


em eee cere ce ee ete eee eee tae ee eee ee nee ae ce a mae ee cee ee me ceemn sme seme “fp ni es ‘its Sos AO AE NA ED A EN GP NE A AD ER A A A EN EN > 


502050203 GENERAL FORMAT EXTENDED VALUE PARAMETERS 


If an extended velue parameter Is greater than one word in tength 
{excluding the descriptor) and is not a pointer-to-procedures then 
lt is passed using an identical format to that for a reference 
parameter. Use of extended value perameters requires that field 
number three of the flag word preceding the paremeter list must 
hava been set to one. 


If an extended value parameter Is a poilnter-to-procedures then the 
first part of thet parameter list entry must contain the left 
Justified PVA of the Code Base Pointer of the procedure In the 
binding section. The second part of the entry must contain the 
left jJustifled PVA of the static ilnk. The 16 bits to the right 
of each of these PVAs is unused and undefined. This can be 
dlagrammed as: 


3} PVA (Code Base) } undef} H Static aak ; undef! 


me abe 


Soh be Se 
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If an extended value perameter is less than or equal to ea word in 
lengths then « copy of the value parameter Is piaced directly in 
the first part of the parameter iist right aligned in a words with 
Sign fill on the teft for Integers and subranges of integerss and 
zero fild otherwise. The essociated word In the parameter fist 
extension for this entry will contain the PVA of a location (which 
must be on a word boundary) in memory where the descriptor Is 
focated. The PVA In the parameter list extension is left aligned 
in a word with the rightmost 16 bits being unused and undefined. 
This can be ciagrammec as: 


i Value (right justified) 3} 3} PVA (descriptor)i undef 3 


_— -_ a 


5 et e5ele4 GENERAL FORMAT SIMPLE REFERENCE PARAMETERS 


Simpie reference parameters are passed elther as a PVA or as a PVA 
pius string descriptor. Parameters consisting solely of e PVA are 
Placed directly in the first part of the parameter jist entry ieft 
aligned in a word; with the rightmost 16 bits of the word unused and 
undafined,. The vaiue of the word in the associated second part (if 
an extension is required) must be the 64-bit inteyer zero. This can 
be diaggremmed as: 


D slenetieanteentimantonntioamel se osiaeieentiontnedarteetetenterteatentn guatentetonetenteesds. ne ce ce ee ee ee re ee oe 2 a ee ee ee ee et + 
3 PVA (object) + undef} H C i 


Simpie reference parameters consisting soleiy of a PVA pius a string 
descriptor are placed directiy in the first part of the parameter 


fist entry with the PVA teft alignea In a word» followed immediately | 


by the two byte tong string descriptor. The value of the word In 


the associated second part (if an extension Is required) must be the 


64-bit intecer zero. This can be diagrammed as: 


ee =e ee mee a + $e eee ee me wee meena + 
$ PVA (object) Siength$ H c ; 
fermen wee oe ee eee fee ww em + $e eee em ee em come ame} 


5 e2 oF e205 GENERAL FORMAT EXTENDED REFERENCE PARAMETERS 


Extended reference parameters require that the non-string descriptor 
be passed indirectiy using the paremeter list extensions regardiess 


se ou we 
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of the size of thet descriptor. Field f3 of the fiag word preceding 
the parameter list must heave been set to one. The first part of the 
parameter list entry will contain the PVA of the object referenced, 
left aligned. If the reference includes a string descriptor then 
thet descriptor is pileacec in the 16 bits immediately following the 
PVAy otherwise those 16 bits are unused and undefined. The . 
parameter list extension for this entry willl contain the PVA of a 
Jocation (which must be on a word boundary) in memory where the | 
descriptor is located. The PVA in the parameter list extension is 
left aligned tra word with the rightmost 16 bits being unused and 
undefined. This can be diaygrammed gs one cof:. 


3; PVA (cebject) i undef i; PVA (descriptor) § undefi 
$e ee ee fern mH 


Sp oe ee ee ee cee ee ee ee oe em ene em om pee oe 00 ce oe on ee en ee on ee a oat. sunaianaieatantinediants a 


§ PVA (object) ifength; 3 PVA (descriptor) $ undef$ 


502050206 GENERAL FORMAT SIMPLE BIT REFERENCE PARAMETERS 


Simple bit reference parameters are passed as a PYA plus a bit string 
descriptor plus a bit string offset. The PVA and bit string descriptor. 
are piaced directiy in the first part of the parameter list entry 
with the PVA ieft siigned in a words followed immediately by the 
two-byte long bit string descriptor. The value of the word In the 
associated second part (an extension is always required) consists of 
a left aligned 48@-bit integer zeros followed by the two-byte long 
bit string offset. This can be diagrammea as: 


pe ee a rn ae ee ef ee ee $ 2 oe on em toe + 
3 PVA (object) slengthi H © soffseti 


52050227 GENERAL FORMAT EXTENDED BIT REFERENCE PARAMETERS 


Fxtenced bit reference parameters require that the non-string descriptor 
be passed indirectly using the parameter iilst extensions regardiess of 
the size of that cescriptor. Field f3 of the flag word preceding the 
perameter list must have been set to one. The first part of the 
paramater iist entry willl contain the PVA of the object referenced, 

left allgneds with a bit string descriptor placed in the 16 bits 
Immediately following the PVA. The parameter iist extension for this 
entry will contain the PVA of a location (which must be on a word 
boundary) in memory where the descrriptor is located. The PVA in this 
parameter list extension is ieft aligned in e words foilowed by the 
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two-byte long bit strings offset. This can be diagrammed as: 


3 PVA (cbJect) Slength! 2 PVA (descriptor) ioffseti 


Fe2eDde2e8 GENERAL FORMAT STRING DESCRIPTORS 


A string descriptor ts a 16-bit unsigned Integer (0.265535) 
Indicating the tength of a string in bytes. When presents it is 
placed in the primary portion of the parameter list immediately 
Following (and in the same word as) the PVA of the odject being 
described. <A string descriptor is required for ail reference 
parameters to objects of type characters subrange of characters 
string, substrings or array over a component type of character,» 
Subrange of characters strings or substring. The string descriptor 
for an array indicates the length in bytes of a singie ciement. 


502050209 GENERAL FORMAT BIT STRING DESCRIPTORS 


A bit string descriptor is a 16-bit unsigned Integer (00..65535) 
Indicating the length of a bit string In bytes. When presents it is 
pleced in the primary portion of the parameter list immediately 
foliocwing (end in the same word as) the PVA of the object being 
described. A bit string descriptor is required for all reference 
parameters to the objects of type bits bit strings bit substring» or 
array over a component type of bits, bit strings bit substring» The 
bit string descriptor for an array indicates the length in bits of 

a single element. 


5020502010 GENERAL FORMAT BIT STRING OFFSET 


A bit string offset Is a 16-bit unsigned Integer with a vaiue in the 
subrange Ceoeo7e Indicating the offset of a bit strings In bitss from a 
byte address. When presents it Is placed right aligned in the extended 
portion of the perameter fist. A bit string offset is required for al 
parameters to objects of type bit, bit strings bit substrings or «erray 
over a component type of bit, bit strings bit substring.» The bit 
string offset for anafray indicates the offset of the first element 

of the array from a byte address. 


5 e2 050201] GENERAL FORMAT ARRAY DESCRIPTORS 


The layout of an erra@y descriptor must adhere to the pseudo-CYBIL 
description given below. Note that "extent" refers to the number of 
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elements In a particular dimensions “stride™ refers to the distance 
(measured In terms of array elements) between two consecutive 
elements of the seme dimension» and “rank” refers to the Number of 
dimensions in the arrays. Array descriptors must be aligned on a 
word boundary. 


array descriptor = array [1 ». rank] of record 
extent: Integer, 
stride: integer» 
lower bound: integers 

recend; 


Se2e5e2ellel Strige 


For languages such as CYBIL and FORTRAN 77s arrays are represented 
and stored as contiguous objects; stride Is a function solely of the 
extents. However the Introduction cf array sections In CDC FORTRAN 
necessitates that en explicit stride be passed in the parameter list 
since sections need not be contiguous in memory; they may have a 
non-unity Increment In each dimension of the errays which must be 
Included in the celculation of the stride. The stride value for 
multi-dimensionail arrays Is calculated differentiy depending upon 
whether arrays ere stored columnwise or rowwlse.. For one 
dimensional arreys the formulas are equivaient. Note that one 
dimensional contiguous arrays have e stride of one. 


For arrays which ere stored columnwise in memory (i.e. with the 
leftmost subscript varying fastest) the Following formula is used: 


f-1 


OE AAD DAR ON OE ma 


stride( ) = incr(i) * E(j) 


G6 “6 Gee 
ee oe me 


J=0 


where stride(i) Is the stride in the i-th dimensions iner(i) is the 
increment of the i-th dimensions anc E(0) is defined to be one. For 
contiguous arrays,» €(jJ) is the extent of the j-th dimension. for 
array secticnss E(j) Is the extent cf the j-th dimension of the 
contiguous array of which this is a section. For exampie If we heve 
the FORTRAN declaration: 

DIMENSION C(15,530) 
then for C we have: iner(1)=l>, iner(2)=1y,). extent(1)=15, 
extent(2)=30» €(1)=15»5 E(2)=30»5 stride{ij=1l» and stride(2)=15. For 
the section: 

C(121082,5 12:22:3) 
we have: Iner(1)=2») Iner(2)=35 extent{1)=5» extent{(2)=4, €1(1)=15,5 
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E(2)=305 stride{1)=2#1=2,) and stride(2)=34*1*15=45. 


For afrays which ere stored rowwise in memory (1.8. with the 
rightmost subscript varying fastest) the foliowing formula is used: 


r+i 


Ct AAD Sa AEP A END EID  - 


stride(4) = inerli) * E(j) 


aa an 
om wis Ce 


J=1+1 


where stride(i) is the stride In the i-th dimensions incr li) is the 
increment of the i-th cimension»s r is the renk of the arrays and 
El(rt+tl) is defined to be one.» Fer contiguous arrays» E(j) ts the 
extent of the y-th dimension. For array sections,» E(j) Is the 
extent cf the j-th dimension of the contiguous array of which this 
Is a section. For exemple If we have the FORTRAN declaration: 
RGWWISE R115, 30) 
then for R we haves r=2s f[tnerll=l» tnor{2)=1,y extent{1)=15>» 
extent(2)=3Gs5 £€1)=15» £(2)=30»5 stride(1)=30» and stride(2)=1. for 
the section: 
R(12103 2, 12:22:33) 
we have: r=2, Iner(l)=2») $Iner(2)=35 extent(1)=5» extent(2)=4, 
E(1)=15» E€(2)=305 stridel1)=2*1*30=60, and stride(2)=3*1=3. 


50205 DATA REPRESENTATION 


The following subsections define the representations of 
data which must be used If an item of a particular type ts 
to be passec between languages. Languages may have types 
beyond these but date of those types cannot be passed to 
other languages. A fanguage is net forced to provide for 
ali of the following deta types. 


5222621 Integer 


An Integer may cccupy 1 to 8 bytes of storage. For 
languages with size allocaticns dependent on the subr enge 
of Integers specifieds, the amount of storage ailocated 
must be the minimum number of bits needed to hold the 
specified range rounded up to the next full byte. 
Subranges that Include neyative numbers must use the 
leftmost bit of the fieid as the sign bit. Negative 
values are represented as negative two's compiement 
quantities. Subranges of onty positive numbers will not 
provide a sign tit. The range of signed integers is 
—-2**63 < i < 2**63-1. The range of unsigned integers is 0 


5-18 
CYBER 180 System Interface Standard 
. 86/02/04 
5.0 COMPILER AND ASSEMBLY CODE CONVENTIGNS 
5e2ebel Integer 


< i < 2¥** 63-1. 


Several languages have an @Qnumerated type called 
ordinals. These are mapped onto the non-negative 
Integers. Allocation rules are the same as for unsigned 
integers. If ordinals ere passed to a language without 
ordinals they must be treated as Integer values and 
vice-versa. 


Two sizes of Integers correspond to easily manipulated 
hardware formats and ere identified as separate subtypes 
of integer to provide for languages with only options for 
half or full word signed Integer values. 


§ 22062121 4 BYTE INTEGER 
A half Integer will be represented by a 4 byte (32 bit) 
quantity in the CYBER 180 Integer format i.e.» a signed 
two's compiement 32-bit quantitys in which the leftmost 
bit is the sign bit. The range of 4 byte integers is 
~2**31 < i < 2**31-1. 


§.22e2601.2 8 BYTE INTEGER 
A fuil integer wxiil be represented by an & byte (64 bit) 
quantity in the CYBER 160 Integer format i.e.» a signed 
two's complement 64-bit quantity, In which the leftmost 
bit is the sign bit. The range of 8 byte integers Is 
—2**63 < 1 < 2**63-1. 


5220602 Elxed Length Charscter_{Stringad 


Fixed length chsracter data will be stored as a sequence 
of conSecutive & bit bytes. The character set will be 
ASCII. 


Real cata wiil be rePresented by an 8 byte (64 bit) 
quantity in the CYBER single precision fioating point 
Formate Ali reai data will tbe normalized. 


522.604 Double Precision 


Double precision data will be represented by a 16 byte 
{128 bit) quantity in the CYBER 180 doublje precision 
Floating point format. It must be normalized. The PVA In 
the parameter list points to the first byte of the double 
precision datum. The second (lower precision half) is 
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located at PVA+8 bytes. The sign and exponent fieids of 
the lower part are considered to be correct at any given 
time. Input and constant assignment routines are 
responsible for insuring corrct signs and exponents upon 
Initial construction of the number. Double precision 
operations wild maintain this format. 


3020605 Comolex 


Complex data will occupy 16 bytes (128 bits) in memory and 
will consist of two reais, where the first real represents 
the "real™ part and the second real represents the 
"jmaginary"” part of the complex quantity. The PVA in the 
Parameter list points to the first byte of the complex 
datum (the real part). The imaginery part is located at 
PYA+8 bytes. 


(522.666 Boolean 


Boolean data occupies a singie byte. A value of one 
Indicates true and a vaiue of zere indicates false. 


5.2.6.7 Poloter 


A pointer is a PVA. It occupies six bytese Pointers may 
Identify data of any of the other data types. The nil 
pointer is defined as a PVA with a ring fleid value of "FF" 
hexadecimal, segment field value “FFF"™ hexadecimal, and 
address fieid vaiue "80000000" hexadecimal. 


5e2e7 DATA ALIGNMENT AND PACKING 


The purpose of the common calling sequence is to provide 
the ability to pass dete between diverse ftanguages. The 
Interlanguage cail ts assumed to represent a smail 
percentage of «ei! calls and generality be used by 
«nowledgeable users. Therafores for performance in the 
word orlented languages (FORTRAN»s In particular) a 
feast-common-cenominator alignment of word IS Used. 


Data types which require 8 bytes to store are required to 
be word alignec to improve performance. This permits the 
use of the jload/store word instructions which afe faster 
than load/store of 8 bytes. The space penalty for uxord 
aligning simpie variables is felt to be small especlaily 
since it costs a maximum of 7 bytes per procedure if all 
the word aligned items are stored contiguously. 
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5e2*e7.1 VYarlatlies 


Varlebles may be of any of the above data types. The 
elignment of eae particular type must be as follows: 


Data Type Alignment 
1-7 Byte Integer Byte 
8 Byte Integer word 
Character (String) Byte 
Real Word 
Double Precision Word 
Compiex word 
Boolean Byte 
Pointer Byte 


5e2e7e2 Siructures 
Structures must begin word aligned. 


Alignment of data to be passed between languages in 
structures must be as follows: 


Data Type Alignment 
1-7 Byte integer Byte 
8 Byte Integer Word 
Cheracter(String) Byte 
Real Word 
Double Precision Word 
Compiex Word 
Boolean Byte 
Pointer Byte 


If a byte aligned item is foilowed by a word aligned item, 
up to seven bytes may be skipped (and ieft unused) to 
regain word alignment. If a byte item follows a byte 
items, they may be in consecutive bytes. 


Se2e7e3el ARRAYS CF VARIABLES 
The arrays rePresent a collection of data items of one 
uniform type. Arrays must be word aligned if the dete 
type they contain is word aligned. Uniess required by an 
external standerd ali languages should store arrays with 
the rightmost subscript varying fastest. FORTRAN, for 
examples is constrained by ANSI standards to store arrays 
with the leftmost subscript varying fastest. If a user 
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passes a multidimensional array between janguéges with 
different storage orderss it is the user's responsibility 
to handle this. Arrays must be byte aligned If all of the 
constituent elements are byte aligned. The parameter list 
PVA Identifies the first element of the array. Subsequent 
@lements must be contiguous and in ascending storage 
address sequence. 


BS e2etlede2 ARRAYS OCF STRUCTURES 
If any element cf the structure is required to be word 
aligned, each array element must stert on a word boundary. 


5 220703203 COMMON BLOCKS 
Items within common biocks muSt be aligned consistently to 
achieve interlenguage communication. Common biocks will 
begin word alignede Alignment of deta within the comaon 
biock wili be the same es for structures. 


$e2e8 LANGUAGE INTERCHANGE TABLE 
The following tebie shows the possibile parameter types 
that may be used between languages. If a ietter appears 
at an intersection in the table» that type may be péssed, 


Types afe encoded as follows: 


J = 1-35 5-7 Byte Integer C = ordinal 
H = 4 Byte Integer I = 8 Byte Integer 
C = Character (string) R = Real 
D = Double Precision Z = Complex 
B = Boolean P = Potnter 
A = array S = Structure 
All = all types of the languase 

+ caliee 

+ 
+ CYBIL PASCAL FORTRAN COBOL PisiI BASIC 
+ 
CALL Op bm re a eo ee ee a a ee a a a 


iJ 

CYBIL : All HIJCBPSAOR ICARD HICBSARD HICBPSAR CR 
8 
% 

PASCAL % HIJCBPSAGR ALL ICA HICBSA HICBPSA C 
8 
% 
8 


FORTRAN IC ARD Ica All ICRDA ICRDZA CRA 
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COBOL $} HICBSARD  HICBSA ICRDA AA HICBRDSA CRA 
3 
9 
PL/I 1 HICBPSAR —-HICBPSA ICRDZA  HICBRDSA All CRA 
9 
s 
BASIC ! CR c CRA CRA CRA All 
+ 


> 2 
E 2 
Notes 


1) PL/I may not have a double precision data type due to 
possible high overhead in supporting the maximum 
precision rules. This wild be determined later. 

2) If arrays are permitted between two languages, the 
type of the array is restricted to the types of 
variables that are permitted between the two Janguages. 

3) <Arrays Of characters in BASIC cannot be passed to 
other langueges» and vice versa. 


5228-1 Extended loterchsrgs 


The lenguage interchange table defines the parameter types 
that can be used between pairs of fanguages. In many 
cases restrictions exist because a particular language 
lacks a data type. For examples BASIC lacks integer type 
since it stores them es reals. In many Instances the type 
mismatches could te mapped by interface code between the 
procedure calis. The following mechanism is proposed to 
support such mepping when and if it becomes a requirement... 


In order to map p8rameterss an Intercept routine must gain 
control from the callers, map things and pass contro! to 
the caliee. The reverse may be necessary upon return. 
The user should not have to be awere of the activities of 
the Interface routine or invoke It directiy. To achieve 
thiss the loader must have a mechanism for detecting the 
need For an Interface routine and inserting same in the 
Calif/return Path. The insertion mechanism can be similar 
to the one used for Analyze Program Dynamics {APD). 
Detection of the need for inserting the interface routine 
can be done with load time argument checking mechanisms. 


For each pair of languages (X and Y) where interface 
mapping is desired» toader tables defining relevant 
information about actual and formal parameters must be 
defined. <A routine (activated during loading by the 
loader if a cail from X to Y is found) wili compare the 
actual and formai parameter fists to determine if mapping 
is required» If not» the ioader simply links as usual. 
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Otherwises, a X to Y mapping routine from 2 library is 
inserted into the tinkage by the loader. 


The X to Y mapping routine receives the actual and formal 
parameter list information from the loader. 


The cailer informaticn is obtained by giving the P address 
ef caller to a toader service routine which returns a PVA 
if the actual peremeter Jist information for the current 
caldj. The caliee information is obtained by giving the 
code base pointer of cailee to a loader service routine. 


The mapping routine uses this Information to transform the 
parameter list and/or deta representations before caliing 
the cailee. When the caliee returnss the mapper will 
recelve control to co any mapping on return parameters. 


54209 REGISTER CALL FUNCTIONS 


In many languages there exist commoniy used sets of 
functions (for examples, mathematical functions) for which 
it is more efficient (though fiess generai) to pass 2 
limited set of parameter values via registers. Up to 
eight (64 bit values) can be passed in registers X2 - X9. 
The first parameter value would be in X2» the second in 
X35 etc. If a couble word vaiue (says doubie precision) 
Is required, it uses two consecutive registers. The 
specific register used for a routine may be inferred from 
the type of the parameter. For examples SQRT{X) will use 
X2 while DCSQRT(C) will use X2 ana X3. These rules eppiy 
to the following data types as parameters: 


1-7 byte Integers 
8 byte Integers 
Real 

Double Precision 
Complex 


Retufn registers for register cali functions (see 5.243) 
must not be saved in calling them. 


No rules are specified for character, boolean or pointer 
data pending identification of functions using these 
argument types that are of general utility. 


The register ceil entry point Is not bound by the 
conventions of the common calling sequencee 


All register cali functions iIntenced for general use must 
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‘ 


also offer an entry point that accepts the common calling 
sequence (5.22 ebtove) and referenceable by a CALLSESG 
instruction. 


53 INIERPRODUCT FILE_USAGE 


Interproduct file sharing between executing subsystems 
Wiili be addressed. It will specify under what conditions 
a product wil! be able to perform I/0 on a file deciared 
by another product. It will also address closing and 
fiushing of files at job st@p termination when 
Interlanguage files are being used. 


504 STORAGE MANAGEMENT 
Purpose 


In order that user object code from different compilers 
can co-exist in one job step while using a timited number 
of segmentss certain conventions must be observed. 


Each user wili tave @ ilmited number of Segments. This 
means that object code from different compilers must be 
abie to share certain data segments. 


5 e421 STANDARD STACK FRAME 


This section describes the standard stack frame which will 
be set up In cenjuncticn with the CALL instruction. The 
purpose of standardizing the stack frame flayout is to 
provide common tracebeck and debugging Interfaces. At the 
same times allowance Is made for e minimum frame for 
Janguages such es batch mode FORTRANs with extensions for 
the complexity of languages such as PL/I. 


A stack frame consists cf two arees: 


1. The save ereéa. 
2. The *environmental” area. 


The save area belongs to the callers the “*envircocnmentai® 
area belongs to the caliee and both exist in the 
appropriete rings. 
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5e4e1l.1 Traceback 


Traceback jis considered to be the lowest level of 
debugging and as such requires the support of both the 
loader and the compilers/assembier. Minimum traceback 
Information will elways be produced to facilitate some 
tracing from within the system. 


The compilers/assembler will produce traceback tables In 
the object module which correlate object-code address of 
entry points anc calls with source-code procedure names 
and line numbers. The loader wili maintain the relation 
of these object code addresses. when traceback Is 
requireds these traceback tables» plus the stacks wild be 
Interpreted to give the source-code names and line numbers 
associated with the PVAs obtained during traceback. In 
full traceback mode entries will exist for each line or 
source statement; in minimum traceback mode only entry 
points and calis are monitored. 


524.1.2 Stetic Chain yvyse__Display 
(See Glossary for definitions.) 


It is not the Intention of this standard to dictate 
whether compiiec code will reference globais via the 
Static chain or a dispisy. Either Is permitted and must 
be maintained by the software. Nete: this oniy applies to 
calis to a nested procedure and hence Is Intraianguage. 


524.2 CHAINS OF ON-CONDITION PROCESSORS 


Software conventions for a standard on-condition processor 
chain format are reauired to ensure that on-conditions can 
be processed correctly. 


The on-condition flag (CCF) In the save area is used to 
Indicate that the stack frame has associated on~-condi tion 
processors. The first eight bytes of the stack frame 
(pointed to by the current stack frame (CSF) of the save 
area) are reserved for the head of the on-condition 
processor chain. Ail cbdject code genefators must 
accommodate the head of chain reservation. If the OCF is 
set in the save areas the eight bytes pointed to by CSF is 
the head cf the on-condition processor chain. If the OCF 
Is not seats the contents of the eight bytes is undefined. 
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50423 DYNAMIC NON-STACK STORAGE 


$e4e3-1 Dynamic. Segments 


NOS/VE provides the capability of creating new segments 
during product execution. Since this increases the number 
of segments in active use and potentially causes a 
performance degradations its use should be limited to 
situations where the aiternatives are less satisfactory. 


524.322 Elxed-Positilon Dynamic Storage 


The fundamental support for fixed-position dynamic storage 
allocation is provided by the CYBIL ALLOCATE statement 
with no IN cpticn>» 


Products coded in CYBIL and needing fixed-position dynamic 
storage should use the ALLOCATE statement directiy. 
Products not coded in CYBIL and needing fixed-position 
dynamic storage may either: 


1) include CYBIL subroutines containing the appropriate 
ALLOCATE statements» or 


2) use a set of common routines which will provide a CMM 
compatibie interface to the ALLOCATE statement. 


5043.3 Variable-Position_Dynamic_Storage 
Var lable-position dynamic storage is not currentiy planned 
for support. 

5e5 COMMON SUPPORT MODULES 


This section willl define modules which wlll be availabie 
for general uS@e 


Math Routines 


For a detalied account of the math routines to be provided 
see C180 Common Modules Math Librery (CMML) ERS with DCS 
log 10 $2929. The routines will offer both a register 
calling sequence and the comMon calling sequence. Entry 
point names will meet the specifications of section 4elel. 


Numeric Conversion Routines 


5-27 
CYBER 180 System Interface Standard 
86/02/04 
5.20 COMPILER AND ASSEMBLY CODE CONVENTIONS 
5.5 COMMON SUPPORT MOCULES 


Routines will be provided for ali products (compiler or 
runtime systems) to perform numeric input and output 
conversion. Tris will ensure that the same numeric 
representation matches the same internal bit value by all 
processors. See eaiso C180 common modules math librery 
(CMML) ERS with DCS tog ID $2929,5 end CMML 
Assembly-language Support System ERS with OCS Jog ID $3410. 


TO I R L A A BDP* Unpecked Numb er- 
n e re) $ $ trailing 170 
+ t 8 n Cc Cc signa 
+ e | g I I combina 
+ 9 r I I tion 
+ e 8 (nondec.) hoiferith 
+ r a 
+ | 
F temtiemaations ed 
FROM i 
3 
a 
Integer H X X 
3 
a 
Real H X{1) 
F ] 
2 
Longreal ; X(1) 
3 
3 
ASCII $ xX X{12) X12) x2) x 
3 
3 
ASCII $5 xX 
Inondec. ) ; 
a 
4 
BDP* ; X 
4 
Unpsecked ; X 
decimal i 
tralling H 
Sian H 
combined ; 
hollerith H 
4 
| 
Number 170 $; xX X 
+ 


*includes aii BOP types except: eiphanumeric 


(1) there are additional routines for handling real and longfeal conversions 
to end from ascii In piecemeal fashion 


{2) transiations moves etc. 
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Utilities 


A set of common utilities wild be provided to carry out 
the following functions: 


‘ Diagnostic Handiing - the formatting of diagnostic 
ae of output and the construction of the diagnostic 
listings. 


‘ Source listing formatting - the formatting of the 
source listing including output of the source lines to 
a print file. 


‘ Storage map/Attribute/Cross Reference listings - the 
formatting cf this listing anc cutput of its contents 
to 2a print file. 


‘ Compiler Usages Statistics - the generation of usage 
statistics messages. 
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6-0 GLOSSARY OF TERBS 


In writing the System Interface Standard it became 
necessary to cierify the meaning cf certain words. This 
glossary contains those words sahich required 

The list wili be extended. 


clarificaticn. 


“~a-~ adjective 


“-n- noun 
~v- verb 


Binary 


Boolean 


FORTRAN 
Booiean 


Diagnostic 


Display 


Error Message 


-h\- 


-h~- 


Of bas® 2. Not tO be used without 
aualification to mean the object code 
cutput from e compiler. Note object 
code files are one of many different 
forms of binary files. 


Data type which can hold the values 
“true” of "faise™. 


Boolean data but required to occupy a 
fuli computer word. 


Generally a part of a larger entity, 
such as listeble cutputs as opposed 
to an error messages which is 
generaily a summary of a command. 
Diagnostics ere generally issued by a 
number of the product sets such as a 
compiler. See aiso - error message. 
Examples A complier may provide a 
singie error message tetiing how many 
errors occurred during compilation 
end produce a diagnostic for eech 
compilation error. 


A mechanism for accessing global 
variapies of a program using 6 table 
of stack frame pointers; one pointer 
for each accessible scope and one 
teble for each active scope. 


Generally a summary of a commands as 
opposed to a diagnostics which is 
generally a part of a jiarger entitys 
such as listable output. The error 
message is generally issued by the 
operating system or by a product via 


6-2 
CYBER 180 System Interface Standard 
86/02/04 


6.0 GLOSSARY OF TERMS 


the operating system. See also - 
diagnostic for an example. 

Invoke -~v- Applies only to splritss witches» 
etc. Procedures are called. 


Job Step ~fM- A job Step is the work done as a 
result of a single command in the Job 
deck/file. Job steps execute 
sequentially within a job. 


Load Module -n- Object information Produced by object 
library generator and input to the 
loader or back into object fiibrary 
generator. Load moduies are designed 
to faciiitete processing by the 
loader. 


Ob ject Module -n- An object module is a unit containing 
code and/or data definition that is 
produced by compliers. 


Db ject Program -n- An object program is a set of obJject 
Modules organized to perform some 
specific function (e.g.s compile 
COBOL statements). <An object program 
is prepared for execution by the 
loader. 


process(ing) -v- Computling). Unrestricted to mean 
either hardware or software. 


Processor -n- Restricted to hardware CPU or PPX. 
May be used for software If 
sufficientiy qualifieds e.g. language 
processor. 


Product -n- Any part of the stenderd software 
which Is covered by the System 
Inerface Standard. 


Product Set -n- That part of the System which Is not 
part of the Cperating System. 


record -n- A unit of data on a flle.w e@ege a 
card Images line image. Not to be 
used without qualification if meaning 
ae"CYy3il® record or “SCL” record. 


Standard -n= Plural-Standerd not Standards when 
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Static chain 


System 


Task 


-h- 


used in the sense of the System 
Interface stendard. 


A mechanism for accessing globel 
varlables of a progfam using tinks 
through the stack frames. 

Ail products (qev.) operating es a 
whole - to be distinguished from 
Cperating System. 


A task Is an instance of execution of 
an object program. Muitiple tesks 
can execute within a single job 

step. Each task has its own address 
space (set of memory segments). 

Tasks may be Initiated either 
synchronously or asynchronously to 
the initiating task. 
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